Миф о том, что в «1С: УТ» есть управление бизнес процессами (BPM)
«УТ» очень хороший продукт для решения тех задач, для которых разработан. Он позволяет управлять торговой деятельностью предприятия. Хорошо анализирует сделки закупки склады финансы. Да, в некоторых случаях он использует механизм платформы «Бизнес-процессы». Но значит ли это то, что торговля предназначена для управления бизнес процессами, либо логикой работы предприятия? – НЕТ, НЕТ и еще раз нет. Эта статья – это крик души. Потому, что реально надоело смотреть презентации или читать описания решения на различных сайтах. Сайтах компаний, которые готовы продать любой продукт «1С» и закрыть глаза на то, что продают клиенту. Апеллируя лишь скромным описанием продукта и даже не понимая сути управления бизнес-процессами. Управление значит, что можно настраивать систему таким образом, что бы ускорять и оптимизировать процессы, проводить различный анализ, выявлять слабые места и многое другое. Для тех, кто не видит разницы между управлением и использованием механизма, постараюсь объяснить на пальцах:
- УТ . Есть три БП в которых нельзя добавить или убрать задачи, поменять тип адресации, логику, нельзя сделать ровным счетом ничего кроме как из конкретных документов привязанных к задачам двигать процесс. По факту это не управление – это использование предложенного варианта логики работы программы с использованием механизма «БП». Да, возможно на основе данного функционала можно разрабатывать свой, не тратя время на какие-то основы.
- CRM . Это реально единственный продукт на платформе «1С», где используется 100% функциональности платформы для работы с механизмом «БП». Это решение где пользователь самостоятельно вносит всю логику работы своего предприятия создавая любые карты маршрутов. Может вызывать свои процессы когда ему нужно и как нужно. И для чего? А как раз для того, что бы этим всем управлять. Что бы смотреть насколько эффективны процессы собирая по ним статистику. Что бы были веские доводы поменять логику. Что бы было все неголословно. Что бы можно было посмотреть все затыки и растягивания резины на этапах. Выкинуть ненужные этапы – увеличить эффективность работы. Вот что такое «Управление». И для этого нужно намного больше, чем три карты с парой блоков.
«В конфигурации реализована базовая функциональность автоматизации бизнес-процессов – универсальные механизмы настройки процессов, контроля и анализа их выполнения, поддерживающие встроенные в типовое решение бизнес-процессы и позволяющие на конкретном внедрении наращивать их состав с меньшими трудозатратами.» . (v8.1c.ru/trade/newtech/ четвертый абзац).
Обращаю внимание на слово «базовая» функциональность для автоматизации.
Это очень далеко от управления процессами предприятия. Отсюда вывод: когда Вам на презентации говорят, что УТ содержит подсистему управление БП – не верьте, когда вам на презентации говорят в УТ есть CRM – не верьте. Это опять же зачатки и базовая функциональность. Еще раз повторюсь – УТ очень хороший продукт, но для других задач – оперативного учета и планирования торговой деятельности, для ее анализа. Концепция «CRM» – это совсем другое. И есть только один по настоящему функциональный продукт на платформе 1С для поддержки концепции CRM на предприятии – Это 1C:CRM. Справедливости ради стоит отметить, что на других платформах существуют тоже достаточно функциональные продукты для поддержки концепции «CRM» на предприятии.
Теги: crm-системы, управление торговлей, 1с, бизнес-процессы
Методология работы любой из программ 1С отражает последовательность проведения хозяйственных операций организации, которые при этом можно объединить в единую цепочку, называемую бизнес-процессом. Чтобы управлять бизнес-процессами, а также упорядочить и автоматизировать эту деятельность, в 1С был разработан специальный механизм.
Преимущества использования механизма регулирования бизнес-процессов в 1С
- Заранее заданная структура бизнес-процесса 1С определяет, согласно принятым процедурам, последовательность действий сотрудников, что обеспечивает системный и формализованный подход.
- Исключен пропуск какого-либо этапа, что не позволяет нарушать установленный порядок работы и существенно уменьшает вероятность возникновения ошибок.
- Постоянный, оперативный контроль, что и на каком этапе находится, а также оценка общего состояния выполняемого сегмента работы.
- Выявление неэффективных решений с последующей оптимизацией бизнес-процессов в 1С.
- Выстраивание (или моделирование) всей структуры бизнес-процессов по организации, что дает общее понимание для принятия управленческих решений разных уровней.
Прохождение в 1С бизнес процесса отображается посредством графической блок-схемы, называемой картой маршрута, которая дает наглядное представление, что, в каком порядке, при выполнении каких условий происходит. Карта маршрутов бизнес-процессов разделена на этапы. Этап в 1С отделен точкой маршрута, в которой нужно выполнить определенную задачу. Задача – это также объект карты маршрута в программе 1С. В задаче указывается исполнитель (или исполнители), кому адресована эта задача, сроки выполнения и важность. Исполнители – пользователи 1С. Адресатом задачи может быть назначен конкретный сотрудник, один из участников рабочей группы* (отдела, подразделения) или сотрудник, занимающий определенную должность (например, кассир, директор, кладовщик).
*Если задание должны выполнить все сотрудники рабочей группы, то такая адресация называется групповой.
Рассмотрим виды маршрутизации как цепочки действий (задач), которые нужно выполнить для реализации бизнес-процесса:
- Жесткая – бизнес-процесс 1С выполняется строго по определенному маршруту;
- Условная – реализация бизнес-процесса 1С зависит от выполнения условий. На маршруте условий может быть несколько, и у каждого – от двух и более вариантов выбора. В зависимости от этого будет построен маршрут;
- Параллельная – бизнес-процесс 1С может разделиться и идти по нескольким параллельным ветвям до конца маршрута или соединиться* вновь на каком-то этапе.
- Свободная – бизнес-процесс 1С не имеет маршрута, выполняясь в зависимости от поставленных задач, автоматически или вручную пользователями.
*Параллельный бизнес-процесс 1С может быть продолжен в точке соединения, например, только при условии ее достижения всеми входящими в него ветвями.
Работу бизнес-процесса 1С мы рассмотрим на примере операции типовой продажи в «1С:Управление торговлей 8.3» посредством демонстрационной базы с сайта ИТС 1С в редакции 11.3.2.193.
Карта начинается с пункта Старт, без которого бизнес-процесс не может быть начат (стартован). Точек старта может быть несколько, но в нашем примере условие выбора появляется после него, и продолжение маршрута зависит от результата заключения сделки.
Далее на блок-схеме присутствуют желтые прямоугольники – точки маршрута с указанием в них сотрудника*, который должен выполнить поставленную задачу. Все завершенные задачи будут заштрихованы. Конечная точка – Завершение. Белые прямоугольные сноски – справки – пояснение к точкам маршрута.
*Для простоты исполнителем на нашем примере схемы в желтых прямоугольниках везде указана должность «Менеджер», но на практике должности могут розниться, в зависимости от полномочий и обязанностей сотрудников, способных выполнить поставленную задачу.
Для запуска бизнес-процесса «Типовая продажа» требуется создание сделки с клиентом, поэтому сначала нужно установить или проверить настройки в соответствующем разделе нормативно-справочной информации (НСИ). Для этого в основном меню необходимо перейти в раздел «НСИ и администрирование – СRM и маркетинг – Настройка CRM» и последовательно установить флажки «Сделки с клиентами» и «Управление сделками».
В данном примере в разделе «НСИ и администрирование – Органайзер» имеется еще ряд настроек для бизнес-процесса, также отмеченных флажками:
- Подчиненные бизнес-процессы и задачи – возможность запускать подчиненные бизнес-процессы и задачи из текущего бизнес-процесса (можно создавать иерархические бизнес-процессы);
- Изменение запущенных бизнес-процессов – разрешение изменять задачи в уже запущенном бизнес-процессе;
- Дата начала задач – возможность изменения даты для старта выполнения задачи;
- Дата и время в сроках задачи – возможность введения сроков в задачах с точностью до минуты.
Помимо этого в рассматриваемом бизнес-процессе существует возможность получения почтовых уведомлений по новым и просроченным задачам. Для этого нужно установить соответственно флажки «Уведомлять о просроченных задачах по почте» и «Уведомлять исполнителей о новых задачах по почте». При необходимости по каждому пункту можно настроить (изменить) расписание получения почты.
Создаем сделку с клиентом (покупателем)
В разделе «CRM и маркетинг – Сделки с клиентами» в списке сделок нужно создать новую сделку и заполнить необходимые поля:
- «Клиент» – покупатель, с которым нужно заключить сделку;
- «Соглашение» – типовое или индивидуальное соглашение с покупателем и с условиями продажи;
- «Наименование» – наименование сделки;
- «Потенциал» – предполагаемый объем сделки в валюте управленческого учета;
- «Вероятность» – вероятность заключения сделки в процентах;
- Поле «Статус» на протяжении всей сделки имеет значение «В работе». В конечной точке статус должен быть изменен в зависимости от результата на «Выиграна» или «Проиграна»;
- В поле «Вид сделки» необходимо выбрать из перечня и установить значение «Типовая продажа».
После того, как карточка сделки будет сохранена, появятся две гиперссылки, отображающие текущее состояние сделки:
- «Этап» обозначает в текстовом виде;
- При переходе по гиперссылке «Карта маршрута бизнес – процесса» информация будет представлена в графическом виде.
На закладке «Участники» можно указать сторонние юр. лица, имеющие отношение к сделке (но это не обязательно).
Для продвижения бизнес-процесса нужно перейти в «Мои задачи» в разделе «Рабочий стол – Мои задачи».
Далее открыть новую задачу и заполнить реквизиты: дата начала и важность. Для выполнения этого этапа требуется создания первичного взаимодействия по сделке: перейти по ссылке «Взаимодействие…» и выбрать из списка нужный вариант (заполнение очень простое). Важно перед сохранением документа установить флаг «Рассмотрено».
Данный этап выполнен.
Далее по правой кнопке мыши в списке задач на этапе «Отразить первичный контакт по сделке» установить статус «Выполнено» (или кнопкой «Выполнено» в форме задачи), после чего автоматически будет создана новая задача . Эту задачу нужно заполнить и выполнить по аналогии с предыдущей.
Автоматически появится следующая задача «Подготовить предложение по сделке» . В форме этой задачи нужно перейти по ссылке .
Чтобы коммерческое предложение стало действующим, нужно заполнить поля на всех трех вкладках. Часть полей заполняется автоматически. По окончании провести и закрыть документ с предложением. После чего текущую задачу можно также считать выполненной, установив статус «Выполнено».
Последовательно пройти следующие два этапа: «Провести презентацию по сделке» (презентация товаров) и «Согласовать условия продаж по сделке» (здесь есть возможность скорректировать коммерческое предложение), после чего список задач будет, как на рисунке ниже, и текущей задачей станет .
Данная задача требует оформления заказа клиента . Нужно открыть задачу и заполнить реквизиты. Далее создать заказ по ссылке «Создать заказ» . Заказ автоматически заполнится данными коммерческого предложения. Его нужно провести, отредактировав при необходимости. В случае предоплаты, потребуется ввод документа об оплате. Все товары в заказе будут со статусом «К обеспечению» . Завершить задачу, установив статут «Выполнено» .
Новой задачей станет этап . Для подтверждения этой задачи нужно наличие пакета документов «Коммерческое предложение», «Заказ клиента», «Реализация товаров и услуг» . В случае предоплаты еще и документ, подтверждающий оплату по сделке.
На форме задачи есть соответствующая ссылка «Документы по сделке» . Перейдя по ней в список документов, создадим документ реализации непосредственно из документа «Заказ клиента» . Для этого все товары в заказе нужно перевести в статус «Отгрузить» и по кнопке «Создать на основании» создать и провести реализацию товара. На форме списка нажать кнопку «Сформировать» . Произойдет обновление пакета документов по сделке. После этого задачу можно перевести в статус «Выполнено» .
Следующей будет задача . Здесь нужно выполнить проверку документов по оплате сделки при условии отсрочки платежка (также по ссылке «Документы по сделке» ). Выполнение этого этапа нужно при наступлении срока оплаты.
Последним этапом будет . Прямо из формы задачи по гиперссылке открыть сделку и изменить ее статус на «Выигранная» . Сохранить изменения в сделке. После чего установить задачу в статус «Выполнено» .
В заключении рассмотрим некоторые интересные особенности бизнес-процессов 1С
- Любую задачу исполнитель может переадресовать другому сотруднику (кнопка «Перенаправить» в форме задачи).
- В задаче можно настроить напоминание себе (кнопка «Напомнить») и в определенный момент получить сообщение. Более того, программисты могут настроить 1С таким образом, что пользователи будут получать оповещения о новых или просроченных задачах. В последнем случае, руководитель или сотрудник, которому поручено (перенаправлено) задание, может предпринять оперативные действия.
- Бизнес-процессы 1С могут быть запущены в автоматическом режиме. Это может быть реализовано с помощью регламентных заданий по расписанию или по событию в системе. Поэтому бизнес-процессы 1С удобно использовать для регулярных повторяющихся процедур. Бизнес-процесс 1С может вызываться другим бизнес-процессом. Для этого в одной или более исполняемых задачах родительского бизнес-процесса должен быть указан вызов подчиненного бизнес-процесса.
- Отметим, что разные этапы бизнес-процесса могут быть адресованы разным сотрудникам, и выполнение следующего действия (задачи) перейдет к другому сотруднику. Например, в случае необходимости предоплаты, без проведения бухгалтерией платежного документа отгрузка товара будет невозможна, а при отсрочке платежа отгрузку должен разрешить ответственный за это сотрудник.
Андрей Колесов
Обсуждая возможности технологической платформы "1С:Предприятие 8.0" , нам уже приходилось подчеркивать, что ее многочисленные новшества связаны с решением трех основных взаимосвязанных задач развития системы:
- повышение производительности и масштабируемости решений;
- расширение функциональности и круга решаемых прикладных задач;
- повышение эффективности разработки, настройки и сопровождения.
В целом можно сказать, что МБП нацелен на повышение эффективности разработки и сопровождения прикладных решений. Однако тут нужно отметить важные качественные отличия от других новшеств этого направления. Дело в том, что если модернизация языка программирования или поддержка групповой разработки рассчитаны на традиционных ИТ-специалистов (программисты, внедренцы), то МБП нацелен на более глубокое вовлечение в процесс проектирования и настройки конкретных прикладных систем специалистов качественно иного уровня - бизнес-аналитиков, консультантов, а также менеджеров заказчика. Более того, эффект МБП с точки зрения клиента проявляется даже в том случае, если пользователь не участвует непосредственно в проектировании бизнес-процессов, а только применяет разработанные кем-то схемы. Возможность формального описания действий системы и визуальное их представление позволяют заказчику лучше понять логику работы решения, в том числе проконтролировать, насколько правильно разработчик выполнил поставленное перед ним задание.
На самом деле, по мнению начальника отдела разработки программ документооборота фирмы "1С" Александра Безбородова, руководившего созданием МБП, новый механизм может даже усложнять разработку решений, так как требует создания и поддержки новых прикладных объектов - бизнес-процессов, их интеграции в готовое решение и связывания с другими объектами - документами, справочниками. Как показывает опыт, при разработке бизнес-процессов поверх готовых конфигураций приходится по-новому смотреть на проектные решения и кое-что переделывать. Сама задача создания бизнес-процесса требует понимания не только основ конфигурирования "1С:Предприятие 8.0", но и предметной области и конкретных потребностей конкретного заказчика. Взамен этот механизм позволяет перенести акцент с управления учетом на управление процессами, автоматизировать потоки работ и соблюдение регламентов.
Таким образом, речь идет еще об одном ключевом направлении развития прикладных решений - повышении уровня их управляемости. Другая важнейшая задача - перейти от схемы, при которой пользователи управляют логикой работы программы, к тому, чтобы программа управляла действиями пользователей. Если раньше сотрудники должны были самостоятельно определять порядок своей работы, то теперь, после описания типичных задач предприятия в виде бизнес-процессов, система сама может формировать для каждого пользователя список задач, которые он должен выполнить.
Появление МБП в прикладных решениях позволяет предприятиям, в том числе и малым, перейти от традиционной функциональной модели управления к современной процессно-ориентированной схеме, качественно улучшить деятельность предприятия за счет реинжиниринга и автоматизации бизнес-процессов. Наиболее эффективной оказывается автоматизация ключевых бизнес-процессов - которые начинаются и заканчиваются во внешней по отношению к предприятию среде.
В информационных материалах "1С:Предприятие 8.0" говорится, что цель механизма управления бизнес-процессами - автоматизация цепочек связанных операций, направленных на достижение общей цели, обычно в контексте организационной структуры, определяющей функциональные роли и связи. Автоматизация бизнес-процессов позволяет повысить качество организации работы и эффективность управления.
Повышение качества. Бизнес-процессы формулируют и реализуют правила выполнения отдельных операций и их взаимосвязь, что позволяет значительно сократить или даже полностью исключить ошибки в ходе выполнения бизнес-процесса, связанные с человеческим фактором. Работа с простым списком заданий позволяет сотрудникам сконцентрироваться на выполнении своих непосредственных обязанностей.
Повышение эффективности. Использование МБП позволяет формализовать организационную деятельность и возложить обязанности по управлению совместной работой сотрудников на прикладное решение, что ведет к более эффективному использованию рабочего времени.
Новые возможности. Данные о выполнении задач и ходе бизнес-процессов могут служить источником информации для оптимизации деятельности и организационной структуры предприятия, выявления узких мест и скрытых ресурсов, и стать средством поддержки процессного управления.
Основные сведения о механизме бизнес-процессов
Бизнес-процессы в "1С:Предприятие 8.0" нужны для того, чтобы объединять отдельные операции (выписка счета, прием наличной оплаты, отпуск товара со склада и т. д.) в цепочки взаимосвязанных действий, приводящих к достижению конкретной цели (например, продажа товара за наличный расчет). Участие сотрудников в жизненном цикле бизнес-процесса организовано при помощи ролевой маршрутизации.МБП обеспечивается сразу несколькими объектами конфигурирования: бизнес-процессы, задачи, регистр сведений и параметр сеанса. Как правило, типы реквизитов адресации задачи и измерений регистра сведений назначаются в виде ссылок на соответствующие справочники, поэтому к четырем перечисленным видам добавляются еще справочники.
Два основных объекта МБП - бизнес-процессы и задачи. Они используют друг друга, а также три вспомогательных объекта (параметр сеанса, регистр сведений и справочники). Вспомогательные объекты не используют ни друг друга, ни основные объекты (рис. 1).
Объект "Задача" предназначен для учета заданий и описывает способ их распределения по исполнителям с учетом организационной структуры предприятия. Адресация заданий сотрудникам определяется реквизитами, в которых можно предусмотреть многомерную ролевую маршрутизацию, например, по ролям, рабочим группам, подразделениям, помещениям, филиалам и т. д. Задачи могут создаваться не только бизнес-процессами, но и другими объектами информационной базы или непосредственно пользователями. Более того, в общем случае исполнителем задания может быть не только сотрудник, но и любая внешняя система, например, другая учетная система.
Понятие задачи фактически определяет лишь интерфейс взаимодействия бизнес-процесса с заданием, выполнение которого в общем случае не связано с выполнением операций в самой системе. Например, бизнес-процесс по ходу своего выполнения может потребовать согласования какого-то вопроса с руководителем фирмы. Сформулированная таким образом задача будет, к примеру, адресована секретарю, который станет решать ее любыми доступными ему способами: по телефону, электронной почте и т. д. Задача будет считаться выполненной, когда в систему поступят сведения о получении нужного согласования.
Задачи имеют самостоятельную прикладную ценность как список заданий, назначенных конкретным исполнителям напрямую или посредством ролевой маршрутизации, и могут использоваться отдельно от бизнес-процессов. При формировании списка задач для конкретного сотрудника используется регистр сведений, который обеспечивает нахождение соответствий роль - сотрудник согласно системе адресации, настроенной в задаче. Как правило, для всех бизнес-процессов реализуется единый список задач.
Объект "Бизнес-процесс" описывает логику выполнения операции для достижения той или иной цели и управляет жизненным циклом созданных бизнес-процессов (экземпляров) - от момента старта до момента завершения. Логика бизнес-процесса (взаимосвязь и последовательность обхода точек маршрута, условные переходы и т. п.) представляется в виде карты маршрута, которая позволяет изобразить маршрут бизнес-процесса в виде связного графа и легко описывать алгоритмы условных переходов и реакцию бизнес-процесса на различные события (рис. 2). При работе пользователя с прикладным решением предусмотрена возможность отображать актуальную карту маршрута для конкретных экземпляров бизнес-процессов с учетом пройденных и активных точек маршрута.
При создании карты маршрута бизнес-процесса используются справочники с предопределенными данными (ролями, подразделениями и т. п.) для установки их значений в атрибуты адресации точек маршрута. Бизнес-процессы создают задачи при переходе на точки маршрута и используют регистр адресации для обработки групповых точек. Параметр сеанса используется бизнес-процессами для интерактивной активации невыполненных задач для текущего исполнителя.
Задачи сообщают бизнес-процессам о своем выполнении, вызывая тем самым их продвижение дальше по маршруту. Регистр сведений используется для отбора задач для текущего исполнителя в соответствии с установленным параметром сеанса. Справочники используются при формировании задач вне бизнес-процессов (например, вручную) или при отборе задач.
Операции, выполняемые в ходе бизнес-процесса, представлены на карте маршрута точками действий (рис. 3, а), которые содержат информацию о том, кто и что должен сделать на данном этапе. Например, для бухгалтера это может быть принять оплату наличными, для кладовщика - выдать товар со склада по накладной, для системного администратора - зарегистрировать нового сотрудника в сети и электронной почте.
Исполнитель может определяться персонально (Иванов) или с учетом ролевой маршрутизации ("Кладовщик", "Руководитель отдела продаж"). При переходе бизнес-процесса на точку действия он автоматически формирует задачи, устанавливая в них предусмотренные реквизиты адресации. Когда исполнитель пометит задачу как выполненную, бизнес-процесс автоматически переходит к следующей точке маршрута в соответствии с картой.
В точке действия возможно также назначение групповых и коллективных задач. В первом случае некое действие должны выполнить все члены группы (например, всем менеджерам нужно предоставить ежемесячный отчет). Во втором - действие должен выполнить только один из членов группы (например, завизировать документ у одного из старших менеджеров). В точке действия можно описать проверку необходимых условий выполнения задачи, интерактивный диалог с пользователем при переходе далее по маршруту и указать, например, какие документы следует открывать при активации задач, связанных с данной точкой маршрута бизнес-процесса.
Бизнес-процессы в "1С:Предприятие 8.0" допускают несколько типов маршрутизации. Заметим, что в реальных картах бизнес-процессов, как правило, встречаются все эти типы.
Жесткая. Карта бизнес-процесса не включает условных и параллельных переходов с жестко определенными адресатами для каждой точки маршрута. Отклонение таких бизнес-процессов не допускается.
Свободная. Адресаты точки карты маршрута бизнес-процесса не установлены и определяются программно или интерактивно в течение жизненного цикла бизнес-процесса.
Условная. Карта маршрута предусматривает проверку условий и переход по соответствующим ветвям (рис. 3, б и в). Переходы могут быть как бинарными (условие), так и множественными (выбор варианта).
Параллельная. Карта маршрута предусматривает разделение бизнес-процесса на параллельные ветви с возможностью последующего слияния (ожидания). Продвижение бизнес-процесса по каждой из параллельных ветвей происходит независимо, по мере выполнения соответствующих задач.
Ключевым понятием в механизме бизнес-процессов и задач в "1С:Предприятии" выступает система адресации, которая обеспечивает возможность не только персональной, но и ролевой адресации задач участникам бизнес-процессов.
Ролевая маршрутизация позволяет назначать задания не только конкретным исполнителям, но и ролям, группам, подразделениям и т. д., как это определено в прикладном решении. Она построена на взаимодействии объектов "Задача" и "Регистр сведений": первый определяет состав реквизитов адресации (роли, подразделения и т. д.), а второй отражает актуальную (соответствующую текущему моменту) информацию о принадлежности сотрудников ролям, подразделениям, рабочим группам и т. д.
С помощью регистра сведений можно реализовать механизм замещения или учета отсутствия сотрудников. Например, если в нем указано, что роль главного бухгалтера исполняет Иванов, а Иванов уходит в отпуск и его обязанности передаются Петрову, то запись в регистре сведений меняется так, чтобы роль главного бухгалтера исполнял Петров. По возвращении Иванова из отпуска соответствующая информация восстанавливается.
Подводя итог, можно констатировать, что механизм бизнес-процессов складывается из следующих основных компонентов:
- многомерной системы адресации задач исполнителям (роли, отделы, организации, группы и т. д.);
- визуального проектирования карты бизнес-процесса;
- генерации задач по исполнителям;
- ролевой маршрутизации;
- перехода по точкам маршрута в соответствии с картой бизнес-процесса.
| Рис. 4. Организация бизнес-процессов в системе "1С:Предприятие". |
Практическая реализация
По ходу статьи мы часто использовали термин "бизнес-процесс", хотя порой под ним понимают разные вещи. С одной стороны, бизнес-процесс - это обобщенное описание последовательности действий при выполнении каких-то деловых задач (например, продажа товара). В данном случае такое описание реализуется в виде программы (только представленной не в кодах, а в виде карты маршрута), которую можно условно назвать частным бизнес-решением. С другой стороны, бизнес-процесс - это выполнение конкретных действий в соответствии с этим описанием (при обслуживании конкретного покупателя), т. е. выполнение написанной ранее программы. В соответствии с терминологией "1С" в первом случае мы будем использовать термин "бизнес-процесс" (БП), во втором - "экземпляр бизнес-процесса" (ЭБП).БП создают разработчики, а пользователи выполняют свои действия с помощью ЭБП. Разработка БП ведется в приложении "Конфигуратор" (инструмент разработки "1С:Предприятие")*, исполнение ЭБП - в среде прикладных решений (среда исполнения "1С:Предприятие").
* Когда речь идет о БП в "1С:Предприятие 8.0", напрашивается параллель с механизмом макрокоманд в Microsoft Office, который также нацелен на автоматизированное выполнение последовательности отдельных функций офисных приложений. Но все же аналогом макрокоманд скорее следует считать давно имеющийся в "1С:Предприятии" механизм "обработок". МБП реализует, с одной стороны, более сложную логику выполнения операций, а с другой - совершенно иной подход к разработке БП. Конфигуратор системы "1С:Предприятие" (рис. 5) предоставляет широкие возможности для создания бизнес-процессов, логика которых задается с помощью маршрутных карт. И здесь нужно сделать еще одно важное замечание. Вообще говоря, программирование бизнес-процессов было возможно в "1С:Предприятии" и ранее, но только на уровне языка программирования. Новый механизм автоматизирует эту процедуру, предлагая визуальные средства проектирования и настройку программы с помощью методов параметризации и сводя к минимуму объем кодирования (или вовсе исключая написание кода). Все это теперь реализовано на уровне платформы, которая содержит объекты метаданных и механизмы, обеспечивающие единообразную реализацию бизнес-процессов в прикладных решениях.
| Рис. 5. Разработка бизнес-процесса в среде "Конфигуратора". |
Подавляющее большинство известных визуальных средств программирования - это по сути лишь надстройка над традиционными редакторами написания кода, автоматизирующая создание этого кода (в качестве примера можно привести и Visual Studio, и Delphi, и различные системы моделирования ПО на базе UML). Результат их работы - программы, реализованные на исходном коде того или иного языка (правда, некоторые поставщики инструментария прячут отдельные модули в двоичном формате, но это скорее исключение). Соответственно разработчик при желании всегда может перейти от визуального проектирования к традиционному программированию "руками".
В этой связи хотелось бы обратить внимание читателя на то, что индустриальный подход к автоматизации бизнес-процессов подразумевает разработку специализированных языков описания БП. Соответственно программы, написанные на таких языках, могут исполняться в любой системе, поддерживающей необходимые стандарты. Пример - язык Business Process Executive Language (см. статью "Автоматизация бизнес-процессов с помощью BPEL" , "BYTE/Россия" No 2"2005).
Механизм бизнес-процессов, реализованный в "1С:Предприятие 8.0", не претендует на подобную универсальность, ориентирован на реализации только в данной среде и оптимизирован для этих целей. Это выражается и в том, что в результате визуального проектирования БП разработчик не получает некоторую программу на исходном коде внутреннего языка "1С:Предприятие 8.0". С некоторой долей упрощения можно говорить, что исходный код создаваемой программы состоит как раз из визуального представления ее логики (карта маршрута), дополненного отдельными фрагментами на языке программирования.
Таким образом, карта маршрута служит одновременно и инструкцией по выполнению последовательности действий бизнес-процесса для системы, и иллюстрацией структуры этих действий для пользователя, и средством отображения текущего состояния бизнес-процесса.
Пример проектирования бизнес-процесса
В качестве иллюстрации рассмотрим пример создания бизнес-процесса "Планирование отпусков". Для этого нужно выполнить следующие основные шаги.Шаг 1. Словесное описание бизнес-процесса:
- всем линейным руководителям - написать предложения;
- линейный руководитель заполняет документ "предложение по графику отпусков";
- менеджер по персоналу рассматривает его - отклоняет, просит уточнить или пересмотреть, принимает;
- в какой-то момент (например, когда большинство сотрудников попали в график) менеджер направляет его руководителю;
- если принимается, то бизнес-процесс завершен.
Сделанное описание позволяет выделить бизнес-роли - линейный руководитель, менеджер по персоналу, руководитель, - которые нужно завести в справочнике "Роли Пользователей" для того, чтобы использовать их для адресации точек маршрута будущего бизнес-процесса. Роли записываются в справочник в виде предопределенных данных.
Чтобы задания доставлялись не ролям, а пользователям, необходимо указать соответствие пользователей данным ролям. Это делается с помощью специального регистра сведений, назначенного как регистр адресации для задач конкретного бизнес-процесса. В регистр нужно занести информацию о том, что, например, Иванов выполняет роль менеджера по кадрам, Петров - это руководитель организации, а Федоров и Сидоров - линейные руководители. Отметим, что соответствие пользователей ролям может меняться с течением времени - скажем, из-за отпусков или кадровых изменений. При этом механизм бизнес-процессов будет обеспечивать доставку заданий соответствующим пользователям с учетом изменений ролей.
Шаг 3. Формирование задачи.
Для работы механизма бизнес-процессов необходим объект "Задачи", с помощью которого будут формироваться задачи для конкретных пользователей. Конфигурирование этого объекта заключается в выборе размерности системы адресации и связывании задач с регистром сведений, в котором прописано соответствие ролей пользователям.
Шаг 4. Проектируем бизнес-процесс.
Создаем первый бизнес-процесс и соединяем его с только что созданной задачей. Затем приступаем к рисованию карты маршрута (рис. 6):
- точка "Старт";
- точки действия в порядке следования;
- добавляем условные переходы;
- точка "Завершение";
- оформляем карту.
Шаг 5. Добавляем формы.
Чтобы пользователи могли выполнять свои действия в рамках данного бизнес-процесса, им нужны экранные формы, в которые они будут вводить соответствующие данные:
- форма предложения по графику отпусков (использует документ "ПланированиеОтпуска";
- форма для рассмотрения всех графиков;
- форма для согласования с руководством.
Для настройки условных переходов (рис. 7) необходимо написать обработчик проверки условия на встроенном языке. Обработчик возвращает результат, который влияет на направление дальнейшего пути бизнес-процесса - направо или налево. Чтобы в процессе выполнения задач у пользователей открывались нужные им формы, нужно написать обработчики "ПриИнтерактивнойАктивации" у соответствующих точек маршрута. Эти обработчики могут открывать формы, документы, выполнять предварительную обработку и т. д.
Шаг 7. Посмотрим, как это все работает:
- создаем новый экземпляр бизнес-процесса;
- все руководители получают задачу "Подготовить график отпусков";
- после составления всех планов они все вместе поступают на рассмотрение кадровику в виде задачи "Рассмотреть графики";
- по результатам рассмотрения часть из них отправляется на доработку;
- после доработки и успешного повторного рассмотрения перед менеджером по персоналу ставится задача согласовать их с директором;
- после успешного согласования бизнес-процесс завершается.
Дальнейшие шаги
Мы закончили создание простейшего бизнес-процесса. При последующей автоматизации операций можно добавить несколько расширенных возможностей.Обратная связь с документами. Например, чтобы при заполнении документа "График отпусков" автоматически инициировался бизнес-процесс согласования графика, и соответствующая задача появлялась у менеджера по кадрам.
Проверка выполнения. Проверка актуальности и правильности составления графика линейными руководителями до передачи на согласование менеджеру по кадрам (например, не разрешать выполнение других задач при незаполненном графике).
Автоматическая сборка отдельных графиков в обобщенный. Можно предусмотреть в карте маршрута точку автоматической обработки, на которой система сама соберет все графики в общий и отправит его на согласование менеджеру по кадрам.
Согласование как вложенный бизнес-процесс. Сам процесс согласования можно выделить во вложенный бизнес-процесс и использовать его в дальнейшем не только в БП "Согласование отпусков", но и в других БП - например, при заключении договоров, выписке счетов и т. д.
Исполнение бизнес-процессов
Как говорилось выше, исполнение бизнес-процессов выполняется в среде прикладных решений (рис. 8). При этом БП можно рассматривать как объект информационной базы, такой же, как документ или элемент справочника. Его жизненный цикл начинается со старта (вызов метода "Старт" или нажатие соответствующей кнопки в форме объекта бизнес-процесса) и заканчивается при достижении точки завершения при условии выполнения всех задач.В свою очередь, задачи - это тоже обычные объекты информационной базы, которые формируются как механизмом бизнес-процессов, так и другими прикладными объектами, и даже вручную. Задача имеет два состояния - выполнена либо не выполнена. Если задача сформирована в рамках бизнес-процесса, то по выполнении она сообщает ему об этом, что приводит к продвижению бизнес-процесса дальше по маршруту (при условии, что соблюдены все необходимые для этого условия). Таким образом, задачи выступают как движущая сила бизнес-процессов.
Для конкретного пользователя работа бизнес-процессов проявляется только в том, что он имеет дело со списком задач, которые должен выполнить. Кладовщик, например, совершенно не должен задумываться о своем участии в каких-то процессах, его дело - при получении задания отпустить товар и зафиксировать эту операцию в системе.
В то же время очевидно, что использование механизма бизнес-процессов дает возможность собирать качественно иную информацию о работе системы управления предприятием, что позволяет руководителям проводить объективный анализ эффективности работы как организации в целом, так и отдельных сотрудников.
Подробнее ознакомиться с механизмом бизнес-процессов, реализованным в "1С:Предприятие 8.0", разработчики и пользователи могут с помощью демонстрационной конфигурации, распространяемой на диске "Информационно-технологическое сопровождение" (ИТС). Там представлены три простых бизнес-процесса ("Продажа товара", "Поручение" и "Согласование"), показывающие различные варианты практического применения нового механизма.
От управления вообще к управлению бизнес-процессамиПрошедший год был отмечен началом широкого применения нового термина - Business Process Management (BPM, управление бизнес-процессами). Поначалу его появление вызвало настороженность заказчиков. Действительно, корпоративное ПО изначально было нацелено на решение тех или иных задач управления предприятием, или бизнесом (в широком понимании этого слова - как деятельности организации), и потому было непонятно, что же революционного заключается в BPM. Не есть ли это традиционный ход ИТ-поставщиков, регулярно обновляющих названия, в общем-то, достаточно хорошо известных методов и технологий? Определенную путаницу в умы ИТ-специалистов вносило и то, что аббревиатуру BPM стали использовать разработчики различных категорий программных продуктов: систем управления документами, ERP-решений и инфраструктурного ПО. (Полезный обзор и анализ концепции BPM сделан в статье "Технология BPM в информационной инфраструктуре организации" , "BYTE/Россия" No 2"2005.)Однако если рассмотреть концепцию BPM более детально, становится ясно, что ее появление действительно связано с некоторыми качественными изменениями в требованиях заказчиков к ИТ, с одной стороны, и предлагаемых вендорами решений - с другой. Хотя ни о какой революции, конечно, не может быть и речи: идет обычный эволюционный процесс развития ИТ, в ходе которого накопление количественных и локальных качественных изменений в какой-то момент времени позволяет говорить о переходе в новое глобальное качественное состояние. В этой связи мы выделим несколько аспектов.
Наверное, правильнее было бы связать реализацию концепции BPM с совместным использованием технологий workflow и EAI (Enterprise Application Integration, интеграция приложений масштаба предприятия). А учитывая необходимость использования собственно прикладных программ, условную формулу BPM можно записать следующим образом: |
Предположим, что к нам поступил заказ реализовать бизнес-процесс заказа товара и получения последующей оплаты по следующей схеме:
При старте бизнес-процесса способ оплаты (через банк или кассу) должен быть известен, чтобы в процессе выполнения произошел переход на соответствующее действие.
Шаг за шагом
И так, начнем. Мы имеем пустую конфигурацию, поэтому необходимо будет добавить все используемые в дальнейшем объекты самостоятельно. Все действия проделаем в несколько этапов:
1) На первом этапе добавим в конфигурацию необходимые справочники с соответствующими предопределенными элементами.
Заполнение предопределенных элементов мы осуществили в соответствии со значениями адресации задач на карте маршрута (см. выше).
2) На втором этапе нужно реализовать механизм, который будет хранить в системе текущего пользователя, а именно ссылку на элемент справочника "Пользователи" связанного с пользователем информационной базы.
Чтобы не усложнять пример, соответствие между элементом справочника "Пользователи" и пользователем информационной базы будем осуществлять по наименованию. При запуске программы система должна сохранить ссылку на текущего пользователя (элемент справочника "Пользователи") в параметр сеанса "ТекущийПользователь". Тип данного параметра - "СправочникСсылка.Пользователи".
На скриншоте выше показан программный код для инициализации значения параметра сеанса "ТекущийПользователь" для текущего пользователя информационной базы. Поиск в справочнике осуществляется по наименованию. Если элемент не найден, то создается новый. В конце стандартной процедуры "УстановитьПараметрыСенаса", в модуле сеанса конфигурации, полученная ссылка на элемент справочника "Пользователи" записывается в соответствующий параметр сеанса.
3) На третьем шаге создадим объект конфигурации "Задача", чтобы в дальнейшем бизнес-процесс адресовал задачи установленным пользователям. Для этого добавим объект конфигурации в ветке "Задачи" и дадим ему такое же имя.
Прежде чем настраивать свойства добавленного объекта, нам необходимо создать регистр адресации задач, по содержимому которого система будет определять конечного исполнителя для задачи (пользователя). Для этого добавим регистр сведений "РолиИсполнителейЗадач" с тремя измерениями. Тип измерений понятен по их именам.
Теперь необходимо в свойстве объекта задач выполнить следующие настройки:
Описанные настройки на вкладке "Адресация" влияют на поведение системы при присвоении исполнителя задачам, создаваемым бизнес-процессом. Немного подробнее:
- Параметр "Адресация" используется для указания таблицы, в которой настраивается адресация задач.
- Свойство "ТекущийПользователь" ссылается на значение, в котором сохраняется текущий исполнитель для задачи (в нашем примере это текущий пользователь).
- Основной реквизит адресации выбирается из реквизитов адресации задачи. Значение этого реквизита будет заполнятся системой при автоматическом создании задачи из текущего исполнителя.
Стоит отменить еще один важный момент: при создании реквизитов адресации, которые будут заполнятся бизнес-процессом автоматически, необходимо установить соответствие их и измерений таблицы адресации.
На этом настройка объекта "Задачи" завершена. Теперь мы можем перейти непосредственно к созданию бизнес-процесса.
4) Четрвертый шаг - он важный самый. Теперь мы начинаем работать непосредственно с бизнес-процессом. Создаем новый объект конфигурации "БизнесПроцесс" в ветке "Бизнес-процессы".
В нем мы добавили реквизит "ОплатаИзКассы" с типом "Булево", чтобы перед стартом бизнес-процесса указать способ выплаты (через банк или кассу). Значение именно этого реквизита будет указывать на какую точку действия необходимо перейти на карте маршрута.
В свойствах бизнес-процесса на вкладке "Основные" укажем для свойства "Задачи" созданный нами ранее объект задач.
Теперь главное - необходимо создать карту маршрута бизнес-процесса в соответствии со схемой, показанной в начале статьи. Для этого перейдем на вкладку "Прочее" и выполним команду "Карта маршрута".
Начертить простую карту маршрута может любой, даже тот, кто впервые зашел сюда. Интуитивно понятная панель инструментов позволяет создавать даже сложные карты маршрута бизнес-процессов. Единственная сложность, которая может возникнуть - это настройка точек маршрута в отношении проделываемых действий. В нашем примере для точек действий нужно установить значения реквизитов адресации. На скриншоте выше показана точка действия, задачи по которой приходят всем сотрудникам подразделения "Бухгалтерия". Соответственно, настройки адресации для нее будут выглядеть следующим образом:
Мы еще вернемся к настройке адресации. Коснемся точки условия. Для нее нам не нужно настраивать параметры адресации, единственное условие для ее работы - описать обработчик проверки условия.
Программный код обработчика приведен на следующем листинге: Процедура ОплатаНаличнымиПроверкаУсловия(ТочкаМаршрутаБизнесПроцесса, Результат) // Если параметр "Результат" равен ИСТИНА, то процесс подет по ветке "ДА", и наоборот. Результат = ОплатаИзКассы; // "ОплатаИзКассы" - реквизит бизнес-процесса (см. выше) КонецПроцедуры
И последний штрих для объекта бизнес-процесса. Добавим собственную основную форму объекта. На ней будем отображать текущее состояние карты маршрута для бизнес-процесса. Для этого добавим новый реквизит формы "Карта" с типом "ГрафическаяСхема" и поместим для него элемент на форму с типом "Поле графической схемы". Для отображения текущего состояния карты маршрута на форму добавим команду "ОбновитьКарту" и соответствующую ей кнопку.
При нажатии на кнопку "Обновить карту" будет выполнен следующий программный код:
& НаКлиенте Процедура ОбновитьКарту(Команда) // Обработчик команды формы ОбновитьКартуСервер() ; КонецПроцедуры & НаСервере Процедура ОбновитьКартуСервер() // Серверная контекстная процедура получения карты маршрута // Конвертируем объект формы в объект бизнес-процесса ОбъектБП = РеквизитФормыВЗначение(" Объект " ) ; // Вызываем метод получения карты маршрута текущего бизнес-процесса Карта = ОбъектБП. ПолучитьКартуМаршрута() ; КонецПроцедурыПримечание: конвертировать обеъкт формы в объект бизнес-процесса необходимо для вызова метода "ПолучитьКартуМаршрута()", поскольку объект формы не поддерживает его.
5) На этом этапе выведем на панель рабочего стола список задач для текущего пользователя. Для этого будем использовать виртуальную таблицу объекта задач - "ПоИсполнителю". Создадим новую форму списка "РабочийСтол", при этом не будем устанавливать ее основной. Откроем ее в редакторе форм и в качестве основной таблицы для динамического списка (реквизит формы "Список") изменим основную таблицу.
После этого добавим созданную форму в рабочую область рабочего стола.
Теперь перейдем к последнему этапу - настройки регистра адресации задач в режиме 1С:Предприятие.
6) Настройка регистра адресации задач - очень важный этап. Запустим программу в режиме предприятия и перейдем в таблицу регистра адресации задач. Создадим там следующие записи:
А теперь подробнее. Первая запись с заполненным измерением "Пользователь" говорит системе, что если для точки действия на карте маршрута в качестве исполнителя установлен пользователь "Сидоров", то задача адресуется непосредственно ему. Если бы мы заполнили измерение "Должность" или "Бизнес-процесс", то задача бы пришла к пользователю только в том случае, если адресация точки маршрута была настроена аналогичным образом.
Если рассмотрим шестую запись из таблицы, где заполнены все измерения, то мы можем заключить следующее: задача пользователю "Бухгалтер" придет только в том случае, если для точки действия установлены в параметрах адресации подразделение - "Бухгалтерия" и должность - "Кассир". В текущем примере для этого условия удовлетворяет одна точка действия:
Обратите внимание, что поле "Пользователь" не заполнено, поскольку мы точно не знаем какому конкретно пользователю нам необходимо адресовать задачу. В соответствии с данной настройкой, задача придет для пользователей, для которых настроены подобные записи в регистре адресации:
Таким образом, основной принцип работы механизма адресации платформы заключается в следующем: задача адресуется пользователю в соответствии со значением основного реквизита адресации в объекте конфигурации "Задача", если совпадают значения остальных измерений регистра адресации (кроме связанного с основным реквизитом адресации) и значений адресации на точке маршрута бизнес-процесса.
На этом задача решена. Проведем небольшое тестирование.
Тестируем
В режиме предприятия выполним старт нового бизнес-процесса.
В соответствии с правилами адресации точки маршрута "Заказ товара", задача должна придти пользователям, для которых в регистре адресации создана запись с подразделением "Бухгалтерия" и пустым измерением "Должность". В нашем примере это пользователь "Бухгалтер" и "Кассир". Запустим программу от пользователя "Бухгалтер" и на рабочем столе видим новую задачу.
Тест завершен, все работает.
Итог
Механизм бизнес-процессов теперь используется во многих типовых конфигурациях. Даже в задачах для сертификации "1С:Специалист" по платформе 8.2 имеется отдельный блок задач по бизнес-процессам. Но несмотря на привлекательность данного механизма, во многом он остается неудобным с точки зрения разработки в таких моментах, как программное формирование карты маршрута и связь объекта бизнес-процесса с другими объектами конфигурации.
| Часто задачи расценивают как вспомогательный объект бизнес-процессов. Однако это вполне самостоятельный объект, наделенный многими свойствами. При правильном подходе задачи могут стать мощным механизмом планирования и управления временем. Данная статья призвана показать пример связи задач и бизнес-процессов, для назначения конкретным исполнителям бизнес-процессов автоматически формируемых задач. | Автор статьи: GROOVY | Редакторы: Волшебник , Добрый Последняя редакция №13 от 04.06.06 | История URL: |
Ключевые слова: задачи, адресация, бизнес-процесс, точка действия, групповая адресация
Исходная ситуация.
Как говорилось в описанной ранее статье () для объекта "Задача" очень важны свойства адресации. В этой статье я постараюсь на простом примере показать как правила адресации могут применяться в контексте задач создаваемых точками маршрута бизнес процессов.Исходная структура метаданных такая:
Справочники: Исполнители, Отделы. Оба без дополнительных настроек, без иерархии и без предопределенных элементов.
Перечисление Роли с двумя значениями: Руководитель и РядовойСотрудник.
Параметр сеанса "ТекущийИсполнитель", тип: СправочникСсылка.Исполнители.
Регистр сведений "ПравилаАдресации" с тремя измерениями: Исполнитель (ведущее, запрет незаполненных значений, тип: СправочникСсылка.Исполнители), Отдел (не ведущее, запрет незаполненных значений не установлен, тип значения: СправочникСсылка.Отделы) и Роль (не ведущее, запрет незаполненных значений не установлен, тип значения: ПеречислениеСсылка.Роли).
Задача "ЗадачиБП" с тремя реквизитами адресации: Исполнитель (основной реквизит адресации, тип: СправочникСсылка.Исполнители), Отдел (тип значения: СправочникСсылка.Отделы) и Роль (тип значения: ПеречислениеСсылка.Роли). В свойстве "Адресация" указан регистр сведений "ПравилаАдресации", "Основной реквизит адресации" - "Исполнитель", "ТекущийИсполнитель" – ссылка не параметр сеанса "ТекущийИсполнитель".
Настройка механизма задач классическая. Умышленно не создано ни одного дополнительного реквизита задачи, так как нас интересует именно работа бизнес-процессов в связке с задачами.
Несколько слов о свойствах бизнес-процессов
Описанием алгоритма бизнес-процесса служит карта маршрута. Точки маршрута карты маршрута бизнес-процесса делятся на две основные категории:1. Точки маршрута, которые порождают задачи. При прохождении бизнес-процесса через эти точки создаются задачи, и до их выполнения бизнес процесс останавливается.
2. Точки маршрута, которые не создают задачи. При прохождении бизнес-процесса через такие точки обычно выполняются, какие либо проверки, обработки.
В свойствах точек маршрута, которые создают задачи можно на этапе конфигурирования жестко задач параметры адресации. Но, как правило, это не конкретный исполнитель, а лишь косвенные параметры адресации.
Обычно точки маршрута, которые создают задачи, обладают возможностью описания событий интерактивной работы пользователя. Точки маршрута не создающие задачи такими событиями не обладают (!).
Одним из свойств бизнес-процесса (БП) является связь с объектом "Задача" в котором создаются задачи точек маршрута этого БП.
С одним объектом "Задача" может быть связано несколько БП.
А что на практике
Создадим простой БП. Ну например БП внутреннего аудита компании.Карта маршрута бизнес процесса будет включать в себя три точки действия. Это основные точки карты маршрута бизнес процесса. Эти точки создают задачи и имеют интерактивные события.
Кроме точек действия любой бизнес процесс должен включать в себя хотя бы по одной точке старта и точки завершения. Эти точки не создают задачи, а используются лишь для описания не интерактивных событий "ПередСтартом" и "ПриЗавершении".
Но нас сейчас интересуют в первую очередь точки действия и те задачи, которые они создают.
Рассмотрим свойства каждой из точек действия подробно.
1. Начать Аудит. Кроме имени для точки действия можно настроить адресацию (Адресация – это группа свойств точки действия). К сожалению, указать на этапе разработки бизнес процесса конкретного исполнителя не получится, так как это элемент справочника – раз, да и для каждого бизнес процесса видимо может быть разный ответственный за проведение аудита – два. Назначать косвенные свойства адресации в нашем конкретном случае нет смысла так как инициатор этого бизнес-процесса сам назначит ответственного (это будет дополнительным реквизитом бизнес-процесса). Как же назначить исполнителя для задачи формируемой точкой действия? Довольно просто. Необходимо перехватить событие создания задач этой точкой действия. Сделать это можно в двух обработчиках событий: "ПередСозданиемЗадач" – этот обработчик событий вызывается когда задачи еще не созданы, можно создать новый задачи и полностью заполнить их свойства; "ПриСозданииЗадач" – здесь задачи уже созданы их можно отредактировать.
В нашем случае лучше воспользоваться обработчиком события "ПриСозданииЗадач", так как необходимо лишь указать исполнителя, а все остальные свойства задачи менять ни к чему.
Процедура НачатьАудитПриСозданииЗадач(ТочкаМаршрутаБизнесПроцесса, ФормируемыеЗадачи, Отказ) Для каждого Задача Из ФормируемыеЗадачи Цикл Задача.Исполнитель = ОтветственныйЗаПроведение; //ОтветственныйЗаПроведение – реквизит БП. КонецЦикла; КонецПроцедуры
Вопрос: Почему цикл? Разве задача не одна формируется? А вот этого никто не знает. Точка действия может формировать сколь угодно задач.
Кстати, если в событии "ПриСозданииЗадач" установить свойство "Выполнена" в Истина, то задача будет выполнена, но ход бизнес-процесса дальше не сдвинется.
В принципе все что связано с первой точкой действия мы сделали. Теперь задача формируемая этой точкой будет наделена конкретным исполнителем, указанным в реквизите бизнес-процесса.
2. Подготовить отчетную документацию. В свойствах адресации этой точки действия установим значение "Роль" – Руководитель. И флаг "Групповая".
Что нам это даст? По правилам адресации заданным в регистре сведений будут созданы задачи для каждого исполнителя являющимся руководителем. Так как задач будет создано (возможно) несколько, то точка маршрута будет считаться пройденной только в том случае, если все задачи будут выполнены.
В принципе флаг "Групповая" отвечает за создание множества задач по подходящим правилам адресации. В том случае если флаг установлен не будет, то задача будет создана одна, но она появится у всех исполнителей в их списке задач (об этом будет чуть ниже).
В любом случае стандартное поведение системы при создании задач можно отключить и описать свои правила создании и назначения исполнителя.
Но давайте посмотрим, как ведет себя стандартный механизм.
Для проверки понадобится инициализировать параметр сеанса. Конечно, хорошо бы это делать при начале работы системы, но нам для удобства проверки как себя ведут задачи, инициализацию можно сделать в форме списка справочника "Исполнители". Я создал форму списка (не меняя настройки, которые по умолчанию предлагает конструктор форм) и в панели действий формы описал новую кнопку "УстановитьПС" (ПС – параметр сеанса). Вот процедура, которая связана с действием этой кнопки:
Процедура УстановитьПС(Кнопка) Исполнитель = ЭлементыФормы.СправочникСписок.ТекущиеДанные.Ссылка; ПараметрыСеанса.ТекущийИсполнитель = Исполнитель; Предупреждение("В параметр сеанса установлен исполнитель " + Исполнитель,60 ); КонецПроцедуры
В справочнике "Исполнители" уже в режиме 1С:Предприятие введу нескольких пользователей.
И регистр сведений "Правила адресации" заполним следующим образом:
Что-то многовато у меня руководителей получилось:)
Самое время создать и запустить бизнес-процесс. В качестве ответственного укажем Петрова.
Надеюсь, что параметр сеанса до того как стартануть БП установили, иначе появится сообщение о том, что он не инициализирован. Все потому что при старте БП создается первая задача, и система проверяет, случайно, не текущий ли исполнитель должен ее выполнить? Для этого системой анализируется значение параметра сеанса, и в том случае если исполнитель совпадает, и у задачи описано событие интерактивной активизации (об этом чуть позже) оно выполняется.
Итак, БП стартовал, первая задача должна была создаться с исполнителем указанным в БП.
Выполним задачу. По правилам адресации вторая точка действия должна создать три задачи:
То есть независимо от того, в каком отделе числится руководитель, для него создается задача. Так действуют правила адресации на задачи с флагом "Групповая".
Могу предположить, что у некоторых вместо трех задач создалась одна без исполнителя, только с указанной ролью "Руководитель". Это связано с тем, что в свойствах задачи "ЗадачиБП" в реквизитах адресации не проставлено соответствие измерению регистра сведений "ПравилаАдресации".
Как ни парадоксально, но в конце этой статьи мы разберем самое классическое создание задачи с назначением исполнителя по косвенным свойствам адресации.
3. Обработать документы. Ничего необычного в этой точке действия нет. В свойствах адресации мы не можем указать признаки адресации (из-за того, что данные в конфигураторе недоступны). В реквизитах бизнес-процесса создадим два новых реквизита значения, в которых и послужат значениями параметров адресации при формировании задачи.
Формы БП в нашей конфигурации нет, по этому новые реквизиты у пользователя появятся автоматически.
Опишем, по аналогии с первой точкой действия заполнение реквизитов адресации в событии "ПриСозданииЗадач":
Процедура ОбработатьДокументыПриСозданииЗадач(ТочкаМаршрутаБизнесПроцесса, ФормируемыеЗадачи, Отказ) Для каждого Задача Из ФормируемыеЗадачи Цикл Задача.Отдел = ОтделАудита; Задача.Роль = РольАудитора; КонецЦикла; КонецПроцедуры
Для наглядного назначения задач сформируем форму списка. В форме списка предусмотрим переключение в режим просмотра задач "По исполнителю". Для этих целей в панели действия формы создадим новую кнопку "ПоИсполнителю" с установленным свойством "Пометка".
В модуле формы опишем две процедуры.
Процедура ПоИсполнителю(Кнопка) ЭлементыФормы.ДействияФормы.Кнопки.ПоИсполнителю.Пометка = НЕ ЭлементыФормы.ДействияФормы.Кнопки.ПоИсполнителю.Пометка; Если ЭлементыФормы.ДействияФормы.Кнопки.ПоИсполнителю.Пометка Тогда ЭлементыФормы.ЗадачаСписок.ОтображениеЗадач = РежимСпискаЗадач.ПоИсполнителю; Иначе ЭлементыФормы.ЗадачаСписок.ОтображениеЗадач = РежимСпискаЗадач.ВсеЗадачи; КонецЕсли; КонецПроцедуры Процедура ПриОткрытии() ЭлементыФормы.ДействияФормы.Кнопки.ПоИсполнителю.Пометка = Ложь; КонецПроцедуры
То есть при открытии форма открывается со всеми задачами, а после нажатия на новую кнопку в форме остаются только задачи по свойствам адресации подходящие текущему исполнителю.
Не забудьте, при проверке, устанавливать в справочнике "Сотрудники" текущего исполнителя. Ну и естественно, что при повторном нажатии форма возвращается в первоначальное состояние.
Форма задач в режиме отображения "По исполнителю" анализируя параметр сеанса, в котором указан текущий исполнитель, и правила адресации в регистре сведений показывает те (активные!) задачи которые по правилам адресации назначены текущему исполнителю.
Теперь можно проверять. Для проверки я введу еще одного исполнителя "Каменский", и в регистре сведений задам новое правило адресации: Каменский, отдел ремонта, рядовой сотрудник.
В стартованном БП укажем значения реквизитов "ОтделАудита" – Отдел ремонта, и "РольАудитора" – рядовой сотрудник.
Выполним три задачи, которые были созданы второй точкой действия.
По третьей точке маршрута была создана одна задача, без указания конкретного исполнителя, но с двумя заполненными реквизитами адресации.
По тем правилам адресации которые заданы в регистре сведений созданная задача должна отображаться в режиме просмотра "ПоИсполнителю" у двух сотрудников: Каменский и Сидоров. У Иванова, не смотря на то, что в регистре сведений он числится прикрепленным к отделу "Отдел ремонта", задача отображаться не будет, так как роль не соответствует правилам адресации.
Указать конкретного исполнителя можно, например, при открытии задачи (кто первый открыл тот и исполняет) или для целей хранения истории при выполнении.
Причем событие "ПриВыполнении" ("ПередВыполнением") отрабатывает не только у задачи, но и у точки маршрута, которая ее породила!
В нашем примере я именно так и поступлю. Опишу событие "ПриВыполнении" точки действия "ОбработатьДокументы". Событие возникает после одноименного события самой задачи.
Процедура ОбработатьДокументыПриВыполнении(ТочкаМаршрутаБизнесПроцесса, Задача, Отказ) ЗадачаОбъект = Задача.ПолучитьОбъект(); ЗадачаОбъект.Исполнитель = ПараметрыСеанса.ТекущийИсполнитель; ЗадачаОбъект.Записать(); КонецПроцедуры
Исходя из того, что было описано выше, можно прийти к следующему выводу.
Для точек действия можно назначить параметры адресации при описании маршрута БП, но только в том случае если значения адресации доступны в режиме "Конфигуратор" (предопределенные реквизиты справочников, значения перечислений и т.п.).
Если при создании задачи по точке действия исполнитель или другие параметры адресации известны можно задать их в событии "ПриСозданииЗадач" или "ПередСозданиемЗадач", ориентируясь на реквизиты БП или другие данные.
Точки маршрута с признаком "Групповая" создают столько задач, сколько исполнителей подходит по правилам адресации, причем правила адресации в этом случае трактуются по указанным значениям адресации в точке маршрута, не указанные значения не учитываются вообще.
Точки маршрута без признака "Групповая" создают одну задачу (если в соответствующем событии точки маршрута не прописано обратное), адресация таких задач стандартная.
Вот и все. Надеюсь эта статья кому-нибудь поможет разобраться с связью задач и бизнес-процессов. Пример специально был взят примитивный, однако он раскрывает все возможные стандартные варианты создания задач точками бизнес-процессов.
Павел Чистов aka GROOVY
Институт технологий сопровождения.
1С:Центр сертифицированного обучения, Санкт-Петербург.
www.its-spb.ru
its(at)its-spb.ru
1С, 1С:Предприятие, 1С:Предприятие 8.0 являются зарегистрированными товарными знаками ЗАО "1С", Москва.
Все представленные снимки экрана, фрагменты пользовательского интерфейса и интерфейса разработчика представлены в целях ознакомления и никаким образом не нацелены на получение какой либо коммерческой прибыли. Никакая часть этих снимков не может быть воспроизведена без согласия правообладателя (ЗАО "1С").