Бизнес задание что это

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

Прежде чем рассказывать, как мы решили задачу «Буше», разберемся с терминологией.

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

Варианты документов бизнес-процесса:

1. Элемент CRM:

• лид;
• сделка;
• контакт;
• компания.

1. Элемент информационного блока:

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

Пользователи бизнес-процессов – сотрудники компании с распределением ролей, которые определяются настройками и маршрутом бизнес-процесса.

Как я выполнил задание бизнес-аналитика ДодоПицца?

В стандартной поставке Битрикс24 есть четыре вида заданий:

• запрос дополнительной информации;
• запрос дополнительной информации (с отклонением) – появился недавно в версии 16.5.0 модуля Бизнес-процессы;
• ознакомление с документом;
• утверждение документа.

Так задания выглядят на схеме в дизайнере бизнес-процессов:

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

Все эти задания и их использование рассмотрены в официальной документации курса Бизнес-процессы (Создание и настройка бизнес-процессов -> Действия -> Задания), поэтому углубляться не будем.

Чем задания лучше задач, чем хуже?

Есть естественное желание при организации рабочего процесса использовать для постановки подчиненным задач модуль “Задачи”. Верным ли будет это? В каком случае надо использовать задания модуля “Бизнес-процессы”? Для этого сведем в таблицу ряд преимуществ для сравнения и потом разберемся.

Преимущество Задания БП Задачи

Уведомления о том, что пришла новая задача	Нет*	Есть
Уведомления о том, что наступил срок выполнения задачи	Нет	Вручную
Уведомления о том, что наступила просрочка	Нет	Нет
Возможность делать цепочки параллельных заданий/задач	Есть	Есть
Возможность делать цепочки последовательных заданий/задач	Есть	Нет
Возможность передавать данные из предыдущего задания/задачи в последующую	Есть	Нет
Структурированность данных результата выполнения	Есть	Нет

Решаю тестовое задание на бизнес-аналитика с зарплатой 200 000 руб.

*Нет встроенной нотификации в уведомления бизнес-чата и/или на почту, есть только “счетчик” в левом меню. Когда появились процессы в живой ленте, с нотификацией стало лучше, но если живая лента быстро пополняется новыми записями, то пользователь также легко может упустить «прилетевшее» ему задание по процессу

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

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

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

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

Задания бизнес-процессов и бизнес-процессы в целом отличаются от задач:

• могут выстраиваться в зависимые последовательные цепочки;
• одно ожидает выполнения другого;
• данные передаются от одного задания/процесса к другому;
• пользователю можно запретить завершить задание, пока он не внес нужные данные.

Ведь можно ставить задачи через бизнес-процесс. Это не решает вопроса, когда нужно последовательно вести процесс?

Верно. Задачи, запускаемые из бизнес-процесса, могут идти последовательно. Но к чему это ведет?

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

То есть это возможно, но неудобно.

И задачи, и задания без напоминаний о сроках теряются. Как быть?

Конечно, люди не роботы, и появление счетчика в левом меню не цепляет глаз. Если их там более пятидесяти, добавление еще одного задания не отображается:

Задания – это один тип действий в конструкторе бизнес-процессов Битрикс24, а уведомления – другой тип. Их просто нужно комбинировать.

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

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

Как контролировать исполнительную дисциплину сотрудников при использовании заданий?

Напомним — бизнес-процессы не действуют сами по себе. Они обслуживают какую-то сущность — одну из четырех сущностей CRM — или информационные блоки. Инфоблоки в Битрикс24 используют в нескольких ипостасях. Одна из наиболее полезных – процессы в живой ленте.

Рассмотрим длительный во времени процесс (месяц и более) из множества последовательных действий (заданий) и небольшой части параллельных. Для примера можно взять процесс ввода/вывода новой продукции нашего клиента «Буше» (сеть пекарен).

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

Руководству нужно было видеть:

• на каком этапе находится запуск той или иной новинки;
• на ком «висит» задача;
• был ли уже допущен срыв срока, кем, на каком этапе и на сколько дней.

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

Постановка задач в Битрикс24 здесь не поможет. А вот процессы в живой ленте могли помочь «Буше».

Ключевых этапов в процессе было выявлено 11, а общее количество заданий, раздаваемых в ходе процесса подчиненным и службам, — порядка 50. Часть заданий ставится в цикле с проверкой условия выхода из цикла. В конце самой важной части процесса — выхода продукции в продажу — участникам комиссии рассылается отчет со сводкой по срокам.

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

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

Эта блок-схема будет работать в облачной версии Битрикс24?

Да! И это дополнительное преимущество этой схемы — в ней нет ни грамма PHP-кода.

А прочитавшим статью до конца бонусы будут?

Конечно! Вы можете скачать «Шаблон бизнес-процесса постановки задания с уведомлениями и контролем сроков». Импортируйте файл у себя в портале, адаптировав под свою ситуацию и свои процессы.

Цитата из курса по бизнес-процессам:

Внимание! Нельзя экспортировать шаблон процесса с одним типом документа в процесс с другим. Пример: экспортировать шаблон из CRM в Списки

Шаблон БП по ссылке предназначен для инфоблоков, экспортирован из процессов живой ленты, но подойдет и для списков.

Источник: www.wehive.digital

Как создать бизнес-задание

«Я использую YouDo для бизнеса, нужны закрывающие документы».

Как найти бизнес-задания

Найти бизнес-задания в общей ленте тоже очень просто — достаточно поставить галочку «Бизнес-задания». Дополнительно можно отфильтровать задания по ключевым словам, категории и подкатегории.

Как это работает

1. Заказчик создает задание с пометкой «Я использую YouDo для бизнеса, нужны закрывающие документы».

На задание откликаются исполнители со статусом ИП, юридического лица или самозанятые.

2. Заказчик рассматривает предложения исполнителей, созванивается с ними, согласовывает стоимость, сроки выполнения, техническое задание.

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

3. Заказчик выбирает подходящего исполнителя. Изменить стоимость бизнес-задания после выбора исполнителя нельзя.

4. Исполнитель выполняет работу.

5. Заказчик отмечает, что задание выполнено. Исполнитель готовит счет и акт и получает оплату за все выполненное задание на расчетный счет.

6. Если заказчик считает, что задание не выполнено, а исполнитель считает, что выполнено, задание попадает в арбитраж.

Частые вопросы

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

— Обязательно ли заключать договор с заказчиком на оказание услуг?
Пользователи заключают договор оказания услуг по взаимной договоренности. Письменное подтверждение сотрудничества может запросить банк или ФНС во время проверок. Договор будет веским аргументом при решении спорных ситуаций, в том числе в суде.

Источник: help.youdo.com

Бизнес-задачи

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

Продукты, используемые при построении решения

• IBM Tivoli Monitoring,
• IBM Tivoli Monitoring for Virtual Servers,

Описание решения

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

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

Логическая архитектура системы комплексного мониторинга представлена в виде 3-х взаимосвязанных уровней:

• уровень оперативного мониторинга;
• уровень консолидации и обработки событийной информации;
• уровень мониторинга бизнес-сервисов.

Уровень оперативного мониторинга отвечает за получение в режиме реального времени данных о функционировании элементов ИТ-инфраструктуры предприятия: сети, каналов, серверов, устройств хранения, ОС, БД, промежуточного и прикладного ПО и пр. Мониторинг ИТ-инфраструктуры реализуется одним из двух способов: с помощью агентов мониторинга (Tivoli Enterprise Monitoring Agent, TEMA), установленных непосредственно на объекте или с помощью удаленных запросов с применением протокола сетевого управления (например, SNMP). В рассматриваемом решении уровень оперативного мониторинга разделяется на три функциональных модуля:

• модуль мониторинга систем,
• модуль мониторинга приложений,
• модуль мониторинга сетевой инфраструктуры.

Модуль мониторинга систем реализует контроль работоспособности, доступности, производительности серверного оборудования и операционных систем. Решение предусматривает интеграцию с утилитами мониторинга от производителей оборудования, такими как IBM Director и HP Insight Manager. Такая интеграция позволяет включить в контур мониторинга аппаратные компоненты серверного комплекса.

Модуль мониторинга сетевой инфраструктуры осуществляет контроль работоспособности, доступности и производительности сетевого оборудования. В рамках оперативного мониторинга сетевой инфраструктуры осуществляется построение и отображение карты сетевой топологии, прием и распознавания сигналов (SNMP-прерываний (трапов)) от сетевого оборудования, контроль состояния критичных характеристик сетевого оборудования (MIB-переменных). Модуль мониторинга приложений обеспечивает мониторинг доступности и производительности промежуточного (middleware) и прикладного ПО, взаимодействия пользователя и прикладного ПО, контроль бизнес-логики приложения. Основными методами мониторинга приложений являются:

• Мониторинг параметров: обработка лог-файлов, сбор информации из БД, получение информации через API приложения и т.п.
• Активный мониторинг: применение синтетических транзакций или эмуляторов действий пользователя. Такой подход позволяет судить о доступности и производительности системы с точки зрения конечного потребителя ИТ-услуги.

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

Если для приложения не существует готового решения в линейке IBM Tivoli, то используется универсальный агент IBM Tivoli Universal Agent, который предоставляет возможность получения информации с использованием различных типов поставщиков данных (http, OBDC, file, script, API, post, SNMP, socket). Применение разрабатываемых на основе универсального агента решений позволяет обеспечить полноценный контроль производительности и доступности всех приложений, обеспечивающих работу бизнес-процессов.

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

• обработку событийной информации, в т. ч. группировку и фильтрацию событий;
• корреляционный анализ с целью выявления взаимосвязи событий и выявления корневой причины (Root Cause Analysis);
• выполнение автоматических реакций на критичные события;
• передачу обработанной информации о события на уровень представления информации мониторинга.

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

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

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

Источник: studfile.net