Autodesk workflows что это

Обновлено: 05.07.2024

Система Workflow – это ИТ-решение для управления «потоком работ», связанными с конкретным этапом бизнес-процесса.

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

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

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

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

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

Системы класса Workflow: назначение, состав, функции

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

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

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

Отличия систем Workflow и BPMS

Если говорить самыми общими словами, то шаблоны Workflow направлены в основном на решение тактических задач, в то время как системы BPM направлены на решение стратегических задач.

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

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

Регламент выполнения работ.
Выполнение работ в соответствии с этим регламентом.

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

Особенности автоматизации с помощью систем Workflow и BPM

Перевод на 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.

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

Давайте подумаем и обозначим проблемы, которые могут возникнуть в процессе разделения задач, и способы их решения. В этом посте будут рассмотрены основные принципы декомпозиции задач при работе в команде. Меня зовут Илья Агеев, я – глава QA в Badoo. Сегодня расскажу, как workflow влияет на декомпозицию, насколько отличаются тестирование и выкладка задач, которые появляются в результате декомпозиции, и каких правил стоит придерживаться, чтобы процесс разработки проходил гладко для всех участников.

Почему это важно?

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

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

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

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

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

Хороший пример – написание юнит-тестов. Зачем мне тратить своё драгоценное время на написание тестов, если у нас есть тестировщики, которые потом и так всё протестируют? А затем, что юнит-тесты необходимы не только для облегчения процесса кодинга – они нужны также и на последующих этапах. И нужны как воздух: с ними процесс интеграции и проверки регрессии ускоряется в десятки, сотни раз, на них базируется пирамида автоматизации. И это даже если не брать в расчёт ускорение вашей собственной работы: ведь «потрогав» код в каком-то месте, вам самому нужно убедиться в том, что вы ненароком что-нибудь не сломали. И один из самых быстрых способов это сделать – прогнать юнит-тесты.

Workflow

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

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

Говоря о workflow разработки, многие, кто использует Git, сразу вспоминают (всуе) о некоем «стандартном git-flow», считая его идеальным, правильным, и часто внедряют его у себя. Даже на конференциях, где я выступал, рассказывая про workflow в Badoo, меня несколько раз спрашивали: «Зачем вы изобрели своё, почему не используете стандартный git-flow?» Давайте разбираться.

Во-первых, обычно, говоря про этот флоу, имеют в виду вот эту картинку. Я взял её из статьи Vincent Driessen “A successful Git branching model”, в которой описывается схема, довольно успешно работавшая на нескольких его проектах (было это в далёком 2010 году).

Сегодня некоторые крупные игроки на рынке хостинга кода вообще предлагают свой флоу, критикуя «стандартный git-flow» и описывая его недостатки; дают свои схемы, рекомендации, приёмы.

Во-вторых, даже у нас в компании у разных команд разный флоу. Флоу разработки серверного кода на PHP, демонов на С/ С++ и Go, флоу мобильных команд – они разные. И пришли мы к этому не сразу: пробовали разные варианты, прежде чем остановиться на чём-то конкретном. К слову, отличается в этих командах не только workflow, но ещё и методологии тестирования, постановки задач, релизы и сам принцип доставки: то, что поставляется на ваши личные серверы и на компьютеры (смартфоны) конечных пользователей, не может разрабатываться одинаково по определению.

В-третьих, даже принятый workflow является скорее рекомендацией, чем непререкаемым правилом. Задачи у бизнеса бывают разные, и хорошо, если вам удалось выбрать процесс, покрывающий 95% случаев. Если же ваша текущая задача не вписывается в выбранный флоу, имеет смысл посмотреть на ситуацию с прагматической точки зрения: если правила мешают вам сделать эффективно, к чёрту такие правила! Но обязательно посоветуйтесь с вашим менеджером перед принятием окончательного решения – иначе может начаться бардак. Вы можете банально не учесть какие-то важные моменты, которые известны вашему руководителю. А, возможно, всё пойдёт как по маслу – и вы сумеете изменить существующие правила так, что это приведёт к прогрессу и станет залогом роста для всех.

Если всё так сложно, да ещё и флоу – это не догма, а всего лишь рекомендация, то почему бы не использовать одну ветку для всего: Master для Git или Trunk для SVN? Зачем усложнять?

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

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

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

Feature branches

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

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

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

Ещё опаснее конфликты, связанные с логикой кода, когда SCM сливает код без проблем (ведь по строкам в файлах конфликтов нет), но из-за изоляции разработки какие-то общие методы и функции в коде изменили своё поведение или вообще удалены из кода. В компилируемых языках проблема, как может показаться, стоит менее остро – компилятор валидирует код. Но ситуации, когда сигнатуры методов не поменялись, а логика изменилась, никто не отменял. Такие проблемы сложно обнаруживать, и они ещё более отдаляют счастливый релиз и заставляют перетестировать код много раз после каждого слияния. А когда разработчиков много, кода много, файлов много и конфликтов много, всё превращается в сущий ад, ибо пока мы исправляли код и перепроверяли его, основная версия кода уже ушла далеко вперёд, и надо всё повторять заново. Вы всё ещё не верите в юнит-тесты? Хе-хе-хе!

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

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

Параллельная работа

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

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

Если цикл релизов быстрый (несколько раз в день вы выкладываетесь на свои серверы), то вполне можно сделать фичи зависимыми друг от друга по стадиям готовности. В примере с Петей и Васей выше создаём не две задачи, а три. Соответственно, первая звучит как «меняем общий метод так, чтобы он работал в двух вариантах» (или заводим новый метод для Пети), а две другие задачи – это задачи Васи и Пети, которые могут начать работу после завершения первой задачи, не пересекаясь и не мешая друг другу.

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

В этом случае можно использовать промежуточную ветку, общую для нескольких разработчиков, но ещё недостаточно стабильную, чтобы быть выложенной на продакшн (Master или Trunk). В нашем флоу для мобильных приложений такая ветка называется Dev, на схеме Vincent Driessen она называется develop.

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

Тут вы можете заметить, что можно ведь тестировать только один раз – после слияния. Зачем тестировать до него, в отдельной ветке? Верно, можно. Но, если задача в ветке не работает или ломает логику, этот неработоспособный код попадёт в общее хранилище и мало того, что помешает коллегам работать над своими задачами, ломая какие-то участки продукта, так ещё и может подложить бомбу, если на неправильных изменениях кто-то решит базировать новую логику. А когда таких задач десятки, очень тяжело искать источник проблемы и чинить баги.

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

Feature flags

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

А вот и будем! В этом нет ничего страшного. Подход, который может быть применён в этой ситуации, – feature flags. Он основан на внедрении в код «выключателей» (или «флагов»), которые включают/ выключают поведение определённой фичи. К слову, подход не зависит от вашей модели ветвления и может использоваться в любой из возможных.

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

Последней задачей в процессе разработки новой большой фичи в этом случае будет задача «включить фичефлаг» (или «добавить пункт меню» в примере с новой страницей).

Единственное, что нужно иметь в виду, используя фичефлаги, – это увеличение времени тестирования фичи. Ведь продукт необходимо протестировать два раза: с включённым и выключенным фичефлагом. Сэкономить тут можно, но действовать следует крайне деликатно: например, тестировать только то состояние флага, которое выкладывается пользователю. Тогда в процессе разработки (и выкладки по частям) задачи её тестировать вообще не будут, а проведут тестирование только во время проверки последней задачи «включить фичефлаг». Но тут надо быть готовым к тому, что интеграция кусков фичи после включения флага может пройти с проблемами: могут обнаружиться баги, допущенные на ранних этапах, и в этом случае поиск источника проблемы и устранение ошибок могут дорого стоить.

Заключение

Итак, при декомпозиции задач важно помнить три простых правила:

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

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

В настоящее время невозможно представить серьезную PDM/PLMсистему, которая не имела бы в своем составе средств автоматизации бизнеспроцессов и документооборота — Workflow. Но, к сожалению, в ряде случаев при внедрении PDM/PLMрешения происходит недооценка значения этой подсистемы, и Workflow используется в лучшем случае как простая система внутренней электронной почты предприятия. В данной статье мы постарались дать читателям более полное представление о возможностях подсистемы Workflow на примере соответствующей подсистемы решения Lotsia PDM PLUS.

Что такое Workflow

Прежде всего давайте разберемся с терминологией. Международная организация Workflow Management Coalition (WfMC) определяет термин Workflow следующим образом: это «автоматизация бизнеспроцесса, полная или частичная, при которой документы, информация или задачи передаются от одних участников другим для выполнения действий в соответствии с набором методологических (процедурных) правил». То есть речь идет об автоматизации не только документооборота, но и бизнеспроцессов. При этом под бизнеспроцессом понимается совокупность взаимосвязанных процедур или мероприятий, которые реализуют бизнесзадачу или цель бизнесполитики, как правило, в контексте организационной структуры предприятия с заданными ролями и отношениями между персоналом. Данное определение представляется нам более корректным и понятным, чем используемое в публикациях ряда отечественных авторов словосочетание «поток работ», представляющее собой прямую кальку с английского.

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

Отличия систем Workflow от систем электронной почты

Люди, не знакомые с системами Workflow, часто спрашивают, зачем им система Workflow, если у них уже есть программа электронной почты.

Основные различия между ними следующие:

Назначение подсистемы Workflow систем PDM/PLM

В системах PDM/PLM подсистема Workflow используется, как правило, для решения следующих задач:

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

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

Основные функциональные возможности подсистемы Workflow систем PDM/PLM

Применительно к реализации в системах PDM/PLM подсистема Workflow обычно обладает следующими функциональными возможностями:

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

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

Описание бизнеспроцессов

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

Графическое представление шаблона бизнес-процесса

Современные системы Workflow в ряде случаев успешно справляются с задачами описания бизнеспроцессов (Process Definition) практически любого уровня сложности, включая вложенные подпроцессы (subprocesses). В подсистеме Workflow программы Lotsia PDM PLUS для описания шаблонов бизнеспроцессов служит визуальный редактор, позволяющий строить описание процессов в режиме draganddrop. При этом описание процесса может включать как неавтоматизированные, так и автоматизированные мероприятия, а также идентифицирует различные мероприятия (activities), методологические правила и связанную управляющую информацию для управления последовательностью действий во время выполнения процесса.

Создание вложенных шаблонов бизнес-процессов

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

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

Такое формализованное описание бизнеспроцессов удовлетворяет требованиям стандартов менеджмента качества серии ISO 9000 в части устойчивой повторяемости процессов.

Экранные формы с контекстными подсказками

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

Типичными примерами шаблонов бизнеспроцессов применительно к использованию в PDM/PLMсистемах являются:

процесс разработки и утверждения проектной, конструкторской или технологической документации по ЕСКД/СПДС (в том числе с многократным представлением документов на утверждение);

процесс проведения изменений по ЕСКД;
процесс обмена информацией с контрагентами и смежными подразделениями;
процесс выдачи задания.

Условия переходов между этапами бизнес-процесса

Проверка бизнеспроцесса

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

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

Запуск экземпляра процесса

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

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

Нотификация и дополнительное оповещение с помощью модуля BeInFlow

Контроль состояния бизнеспроцесса

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

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

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

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

Использование специализированных функций

Помимо возможностей, стандартных для профессиональных систем Workflow (таких как информационные рассылки, управление правами доступа и т.п.), Lotsia PDM PLUS включает ряд настраиваемых специализированных функций. Одной из них является возможность организации электронных голосований. При этом участники голосования могут голосовать по нескольким вопросам в рамках одного голосования, высказывать особое мнение и делать комментарии. Итоги голосования могут обрабатываться различным образом и отображаться в наглядной форме.

Дополнительно к голосованиям подсистема Workflow системы Lotsia PDM PLUS имеет механизм пользовательских календарей, позволяющий быстро и удобно назначать персональные события.

Просмотр текущего состояния карты бизнес-процесса

Встроенный контроль исполнения бизнес-процесса в Lotsia PDM PLUS

Встроенный клиент электронной почты и интеграция со средствами ввода информации

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

Отчет по текущему состоянию бизнес-процессов

Данные функции делают удобным обмен информацией с организациями, не имеющими систем PDM/PLM.

Workflow и реинжиниринг бизнеспроцессов

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

Для анализа и оптимизации бизнеспроцессов можно воспользоваться накопленной статистикой по выполненным процессам. Данные по процессам при этом, с целью снижения нагрузки на рабочий сервер системы PDM/PLM, имеет смысл выгрузить в отдельную базу данных и анализировать с помощью специальных средств (OLAP и т.п.). Но первичный анализ можно проводить и с помощью входящего в состав решения Lotsia PDM PLUS генератора отчетов.

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

Дерево истории переписки

Данные возможности подсистемы Workflow облегчают поддержку требований стандартов серии ISO 9000 в части аудита бизнеспроцессов.

П оложительный опыт внедрения Workflow

Как показывает опыт внедрения подсистемы Workflow решения Lotsia PDM PLUS, производительность труда за счет внедрения автоматизации бизнеспроцессов возрастает в среднем в несколько раз, а для отдельных задач (например, выдача заданий смежным подразделениям в проектных организациях) — в десятки раз.

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

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

Самое главное и, как ни странно, трудное понятие - это само
workflow . Вроде бы все ясно, но в объяснениях даже большинство экспертов
обычно сбиваются на примеры (в этом, конечно, нет ничего страшного - попытайтесь
дать четкое определение слову «каламбур»).

Так, недавно наш вице-президент, вернувшись из очередной
зарубежной командировки, был совершенно очарован некоторыми ассоциациями.
Представьте себе человека, стоящего под чудным лозунгом «True workflow »
(наверное, многие смотрели сериал «Настоящие охотники за привидениями» - эта
стильная вывеска имела приблизительно тот же смысл, но только в срезе
workflow ). Когда заинтригованный руководитель поинтересовался у белозубого
великана, что сие означает, тот снисходительно начал рассказывать историю о
чудной вещи, почте, которая служит для передачи информации в другое место. Все
было очень интересно, но непонятным оставалось только одно - а причем здесь
workflow .

Тогда американец в доходчивой форме, взяв ручку и листок
бумаги, разбил это слово на составляющие «work» и «flow» и разъяснил, что работа
делается, а информация пересылается.

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

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

Не стоит путать также программы с элементами workflow
(о которых тоже говорится, что в них реализован механизм workflow ),
какой, в частности, является MS Windows Explorer, ведь она осуществляет движение
документов между директориями и даже отдельными компьютерами, с
полнофункциональными одноименными системами .

Основные вопросы

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

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

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

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

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

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

Причина внедрения системы

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

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

Именно для решения данного круга вопросов и предназначены в
первую очередь workflow - системы - описание правил выполнения
заданий и осуществления оперативного управления пользователями и работами.

Чем управлять?

Итак, предварительно ответив на первый вопрос - зачем, мы
плавно переходим к разделу «Чем управлять?». Какими данными будут манипулировать
сотрудники, участвующие в том или ином деловом процессе.

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

Если вам необходимо автоматизировать работу контрактного
отдела, львиную долю которой составляют неструктурированные документы, как-то:
файлы, таблицы, рисунки, здесь уже целесообразнее использовать универсальные
workflow -комплексы, наряду с формализованными данными имеющие также и
расширенные механизмы для операций с простыми файлами (см. табл.1).

созданных в собственном редакторе

созданных сторонними программными

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

Рис.1 Редактор карт ActionWorkflow

Рис.2 Редактор карт WorkRoute II

Рис.3 Редактор карт FormFlow

Средства описания процесса

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

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

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

Наличие графического редактора карт

точка входа в карту

Наличие встроенной системы скриптов

Поддержка внутренних переменных карты

Кто управляет выполнением работ?

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

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

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

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

Буквально пару слов стоит сказать о назначении сотрудников на
работы. Практически все workflow -продукты поддерживают либо персональное
назначение на выполнение этапа (например Иванов И. И.), либо по ролям (по
группам) - допустим бухгалтерия.

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

Во второй половине 90-х годов появились так называемые
интеллектуальные workflow - системы (к числу которых можно смело
отнести WorkRoute II - детище компании ВЕСТЬ АО), которые в отличие от своих
предшественниц могут назначить на исполнение конкретной работы наименее
загруженного сотрудника отдела.

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

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

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

Читайте также: