Главная страница Visual 2000 · Общий список статей

Автоматизация бизнес-процессов в системе "1С:Предприятие 8.0"

Андрей Колесов

© Андрей Колесов, 2005
Авторский вариант. Статья была опубликована c незначительной литературной правкой в журнале BYTE/Росся (N 03/2005, с.73)


Рассказывая о возможностях технологической платформы...

Рассказывая о возможностях технологической платформы "1С:Предприятие 8.0" (см. например, "1С:Предприятия 8.0" расширяет свои возможности", BYTE 10/2004), мне уже приходилось подчеркивать, что ее многочисленные новшества связаны с решением трех основных взаимосвязанных задач развития системы:

Одним из важных новшеств "1С:Предприятие 8.0" (1СП8) является создание механизма бизнес-процессов (МБП), который был реализован на уровне бета-версии в начале лета прошлого года и должен появиться в рабочем варианте в релизе 8.0.10 до конца первого квартала 2005 г. Подчеркнем, что МБП является составной частью технологической платформы, что означает, что эти возможности могут стать доступными всем прикладным решениям, созданными на основе 1СП8.

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

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

  2. На самом деле (сошлемся при этом на мнение начальника отдела разработки программ документооборота фирмы "1С" Александра Безбородова, руководившего созданием МБП) МБП может даже усложнять разработку решений, т.к. требует создания и поддержки новых прикладных объектов — бизнес-процессв, требует их интеграции в готовое решение и связывания с другими объектами — документами, справочниками. Как показывает опыт при разработке БП поверх готовых конфигураций приходится по новому смотреть на проектные решения и кое что переделывать. Сам процесс создания бизнес-процесса требует понимания не только основ конфигурирования 1СП8 но и хорошего понимания предметной области и конкретных потребностей конкретного заказчика. Взамен этот механизм дает возможность перенести акцент с управления учетом на управление процессами, автоматизировать потоки работ и соблюдение регламентов.

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

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

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

В начало статьи

Основные сведения о механизме бизнес-процессов

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

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

Два основных объекта МБД — бизнес-процессы и задачи. Они используют друг друга, а также три вспомогательных — параметр сеанса, регистр сведений и справочники. Вспомогательные объекты не используют друг друга и основные объекты (рис. 1).

Рис. 1. Схема взаимодействия объектов механизма управления бизнес-процессами

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

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

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

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

Рис. 2. Карта маршрута описывает логику бизнес-процесса в наглядном виде

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

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

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

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

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

Бизнес-процессы в 1СП8 допускают несколько видов маршрутизации:


а)

б)

в)

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

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

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

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

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

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

А общая логика выполнения бизнес-процессов выглядит примерно так (рис. 4):

Рис. 4. Организация бизнес-процессов в "1С:Предприятии"

В начало статьи

Практическая реализация

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

В соответствии в терминологией "1С" в первом случае мы будем использовать термин "бизнес-процесс" (БП), во втором — "экземпляр бизнес-процесса" (ЭБП). БП создают разработчики, с пользователи выполняются свои действия с помощью ЭБП. Разработка БД ведется в приложении "Конфигуратор" (инструмент разработки "1С:Предприятия", рис. 5), исполнение ЭПБ — в среде прикладных решений. (среда исполнения "1С:Предприятие", рис. 6). <*>

<*> Говоря о БП в 1СП8, невольно хочется провести параллель с механизмом макрокоманд, используемым в MS Office, который также нацелен на автоматизированное выполнение последовательности отдельных функций офисных приложений. Но все же аналогом макрокоманд, скорее, являются давно имеющий "1С:Предприятии" механизм "обработок". МБП, с одной стороны, реализует более сложную логику выполнения операций, а с другой, — совершенно иной подход к разработке БП.

Рис. 5. Разработки бизнес-процесса в среде "Конфигуратора"

Рис. 6. Исполнение бизнес-процесс в прикладном решении

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

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

Подавляющее большинство известных визуальных средств программирования, по сути являются лишь надстройкой над традиционными редакторами написания кода, автоматизируя создание этого кода (тут можно привести примеры и Visual Studio, Delphi и различных систем моделирования ПО на базе UML). Результатом их работы являются программы, реализованные на исходном коде того или иного языка. (Правда, некоторые поставщики инструментария прячут отдельные модули в двоичном формате, но это скорее исключение.). Соответственно, разработчик, в принципе может при желании всегда визуального проектирования перейти к традиционному программированию "руками".

В этой связи хотелось бы обратить внимание, что индустриальный подход к автоматизации бизнес-процессов подразумевает разработку специализированных языков описания БП. Соответственно программы, написанные на таких языках, могут исполняться в любой системе, поддерживающей необходимые стандарты. В качестве примера можно привести язык Business Process Executive Language (см. статью "Автоматизация бизнеспроцессов с помощью BPEL", BYTE 02/2005).

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

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

В начало статьи

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

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

Шаг 1. Словесное описание бизнес-процесса:

Шаг. 2. Определение адресации

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

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

Шаг 3. Формирование задачи

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

Шаг 4. Проектируем бизнес-процесс:

Создаем наш первый бизнес-процесс и соединяем его с только что созданной задачей. Затем приступаем к рисованию карты маршрута (рис. 7):

Рис. 7. Карта маршрута бизнес-процесса "Планирование отпусков"

Шаг 5. Добавляем формы

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

Форма предложения по графику отпусков (использует документ "ПланированиеОтпуска" Форма для рассмотрения всех графиков Форма для согласования с руководством

Шаг 6. Программируем.

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

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

Шаг 7. Посмотрим, как это все работает:

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

В начало статьи

Дальнейшие шаги

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

В начало статьи

Исполнение бизнес-процессов

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

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

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

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

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

В начало статьи

ВРЕЗКА. От управления вообще к управлению бизнес-процессами

Прошедший 2004 год охарактеризовался началом широкого использования нового термина - Business Process Management (BPM, управление бизнес-процессами). Поначалу его появление вызвало настороженность заказчиков. Действительно, применение корпоративного ПО изначально нацелено на решение тех или иных задач управления предприятием, т.е. бизнесом (в широком понимании этого слова, как деятельности организации), и поэтому было непонятно, что же революционного может заключаться в BPM. Не является традиционными ходом ИТ-поставщиков, регулярно обновляющим названия, в общем-то, достаточно хорошо известным методам и технологиям? Определенную путаницу в умы ИТ-специалистов вносило еще и то, что аббревиатуру BPM стали использовать разработчики различных категорий программных продуктов: систем управления документами, ERPрешений и инфраструктурного ПО.(Полезный обзор и анализ концепции BPM приведен в статье "Технология BPM в информационной инфраструктуре организации", BYTE/Россия N 02/2005.)

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

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

Создание комплексных систем управления предприятия требует объединения разнородных решений (в том числе унаследованных). Наиболее эффективное решение задач интеграции данных и приложений в системах масштаба предприятий возможно на уровне платформенного ПО. В настоящее время одним из наиболее перспективных направлений создания разнородных распределенных систем является использование технологии Web Services (см. также статью " Автоматизация бизнес-процессов с помощью BPEL", BYTE 02/2005).

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

Говоря о концепции BPM, необходимо сказать о ее связи с технологиями Workflow (управление потоками работ). Их родство является вполне очевидным, однако ни в коем случае не нужно делать знак равенства между ними (к сожалению, это делается в некоторых публикациях даже в профессиональных ИТ-изданиях). Методы Workflow, пик популярности которой в мире пришелся на последние годы прошлого столетия, накладывают на процессы автоматизации модель, ориентированную в первую очередь на документы и задания. Данный подход ограничивает применение технологий Workflow в основном автоматизацией ручных процессов обработки документов. У BPM таких ограничений нет: участниками процессов могут в равной мере выступать и конечные пользователи, и информационные системы, и другие процессы, а документы и задания рассматриваются лишь как частности, влияющие на реализацию бизнес-процессов, но не носящие основополагающего характера. Все это позволяет применять BPM для более широкого круга вопросов, нежели тот, для которого изначально были разработаны системы Workflow.

Наверное более правильным было бы связать реализацию концепции BPM с совместным использованием технологий Workflow и EAI (Enterprise Application Integration, интеграции приложений масштаба предприятий). А учитывая необходимость использования собственно прикладные программы, условную формулу BPM можно представить в таком виде:

BPM = Workflow + EAI + ERP(Enterprise Resource Planning) + ECM (Enterprise Content Management)

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

В начало статьи