Проблема: договора с крупными заводами требуют согласования нескольких лиц компании, при этом документы должны согласовываться без затягивания сроков. Решение: использовать бизнес-процессы для согласования договоров. Так как компания уже работала в Управление торговлей и нужна была ещё CRM система, встроили в УТ продукт CRM Корп, в котором есть возможность настраивать бизнес-процессы в пользовательском режиме, используя механизм блок-схем. В системе есть отчетность, позволяющая видеть просроченные этапы и на каком этапе находится каждый процесс.
Блок CRM в 1С:Управление торговлей 11
Типовые решения 1С постоянно развиваются и программный продукт УТ – не исключение. С новым витком развития этот продукт получила довольно функциональный блок CRM. Однако, по умолчанию он выключен. Включение блока осуществляется в настройках. Это решение, в котором пользователь самостоятельно определяет логику работы своего предприятия, создавая карты маршрутов.
Собирая по процессам статистику, можно определять эффективность текущих бизнес-процессов, а изменяя или удаляя некоторые этапы, увеличить эффективность работы.
Урок №8 — Бизнес-процесс, согласование документов в Битрикс24
Создание схемы бизнес-процессов по согласованию документов на базе 1С:CRM КОРП
Были обследованы бизнес-процессы компании и созданы карты маршрутов. Также были созданы шаблон и схема процесса согласования, комплексный маршрут для согласования документов, распределены роли и пользователи ответственные за свои этапы согласования. встроили в УТ продукт CRM Корп, в котором есть возможность настраивать бизнес-процессы в пользовательском режиме, используя механизм блок-схем. Была настроена отчетность по контролю сроков выполнения действий по этапам и процессам, и организована рассылка контрольных отчетов руководству компании.
Результаты внедрения Схемы бизнес-процессов по согласованию документов на базе 1С:CRM КОРП
Самый большой выигрыш был получен по качеству принимаемых решений — несогласованные договоры стали невозможны! Мы внедряем «1С:Документооборот» в средних и крупных компаниях уже достаточно долго и за это время накопилась статистика по проектам, которая подтверждает, что существенно ускоряются темпы роста бизнеса после того, как компания освобождается от бумажной рутины.
Запрос на консультацию по Созданию схемы бизнес-процессов согласования документов на базе 1С:CRM КОРП
Если вашему предприятию необходимо согласовывать документов на базе 1С:CRM КОРП, компания Асист-ПРО готова создать для вас похожую систему. Звоните нашим специалистам или присылайте запрос на консультацию! Компания Асист-ПРО создаст на основе 1С:Документооборот и 1С:CRM КОРП Систему согласования документов!
Источник: asyst-pro.ru
Система согласования. Как мы велосипед изобретали
Бизнес-Процесс согласования документов или Листы согласования В Битрикс24
Продолжаем рассказывать о том, как мы улучшаем жизнь не только нашим клиентам и партнерам, но и сотрудникам компании. Речь пойдет о внедрении системы согласования. Сознательно не указал согласования “чего”, так как в дальнейшем станет понятно, что чисто теоретически, согласования “всего”.
Размышления о системе согласований
Изначально в нашей компании, как и во многих других, в которых мне пришлось поработать, а также в которых был “гостем” или просто наслышан от своих знакомых, согласование договоров велось (и на момент написания статьи пока еще ведется), посредством обычной переписки в почте. Естественно это устраивает компании с небольшим количеством персонала и контрагентов.
Нет особой необходимости придумывать и внедрять системы из-за подписания одного-двух договоров в месяц (а то и год) с единолично принимающим о подписывании решении генеральным директором. Аналогичная ситуация наблюдалась и с оплатой счетов. Каждый сотрудник, который взаимодействует с контрагентами и которому необходимо что-то оплатить, запрашивает счет и по почте отправляет в бухгалтерию с просьбой “оплатить”. При этом, далеко не всегда бухгалтерия оплачивает счета без предварительного согласования оплаты с непосредственным руководителем сотрудника и/или руководством компании. При определенных условиях цепочка согласований может “укорачиваться” или наоборот “удлиняться”.
Пока сотрудников не много и каждый знает всех своих коллег, кто кем является и кто кому руководитель — особых проблем не возникает. В ручном режиме и при определенных условиях заявки на оплату проходят согласования в режиме переписки и оплачиваются (либо отклоняются). Но наша компания растет и с определенного момента мы перешли ту незримую черту, после которой необходимо задуматься об автоматизации данных процессов и о необходимости внедрения чего-то нового.
Наши хотелки
У нас были свои минимальные требования к системе:
- User-friendly интерфейс и крайне желательно web-ориентированный (без надобности установки клиентов)
- Гибкость настройки
- Мы хоть и не клинические, но параноики. Поэтому сервисы, в которых может появляться конфиденциальная информация, хотим держать в нашем закрытом периметре
Не могу сказать, что системы плохие. На самом деле почти все системы позволяют выполнить основные наши “хотелки” и даже больше, чем нам нужно. Но, как обычно, дьявол кроется в деталях.
В первую очередь — интерфейс. Не привыкли мы пользоваться интерфейсом в стиле “1С”. Нам нужен простой, интуитивно-понятный интерфейс, в котором мы будем производить минимум действий для получения максимального результата (а кто же так не хочет?).
Во вторую очередь — цена (одномоментно заплаченная и затем стоимость владения продуктом в целом). Нам далеко не все нужно в системах, которые предлагаются из коробки. Но при этом платить приходится сразу за все. А так как сейчас многие переходят на систему подписки, то платить приходится постоянно и сумма, как обычно, зависит от множества условий (кол-во пользователей/подключений, возможности работы в облаке, дополнительные опции, модули и т.п.). А “соскочить” с системы, если вдруг цена перестала устраивать — проблематично.
В-третьих — нет возможности “управлять” своими «хотелками».
Реализация
Не буду долго расписывать, как и почему в итоге мы остановились на решении “придумать велосипед” и написать свою систему электронного документооборота. Решение принято — нужно делать. Мы уже прошли болезнь попытки реализовать продукт без требований, поэтому первично стартовал процесс написания ТЗ и его согласования. Благо перед глазами у нас были примеры реализаций, поэтому формирование прошло довольно безболезненно.
Единственное, над чем пришлось нам поломать копья — это в процессе разработки архитектуры не поддаться на соблазн удовлетворить требования “как есть”, в ущерб гибкости и дальнейшему удобству эксплуатации. Соблазн был велик, особенно у основного заказчика, так как срок реализации и внедрения сокращался бы в 2 раза. Но нам удалось убедить и руководство, и себя, что “лучше день потерять, потом за 5 минут долететь”. И считаю, что мы сделали правильный выбор.
Лучше день потерять, потом за 5 минут долететь.
Стек “стандартный” — .Net Core 2 и EntityFramework, Angular 4, MS SQL, так как имеем в применении инструментария и технологий довольно большой бэкграунд. Хотя СУБД для нас особого значения не имеет по понятным причинам. При необходимости перейдем на какую пожелаем.
В итоге получился продукт, который удовлетворяет важным для нас требованиям:
- Один воркфлоу — разные участники согласования (связан со следующим пунктом)
- Условия пропуска этапа согласования по заданным условиям (любое поле в заявке можно добавить в условие с заданной проверкой и на основании валидности условия определяется необходимость перехода на очередной шаг согласования или его “пропуск”)
- Наш “фирменный” интерфейс
- Задание дефолтных значений справочников (как пользовательских, так и системных). Пользовательский справочник — это сущность, позволяющая задавать элементы самостоятельно пользователем. Созданные элементы будут доступны только ему. При этом в такой справочник администратор системы может внести общие элементы, которые будут доступны всем пользователям системы
- Определение наиболее часто использующихся элементов справочников для каждого пользователя и формирование списков в интерфейсе исходя из данной статистики (сортировка)
- Полностью настраиваемые из админки схемы (структура и свойства полей для заполнения) и представления (расположение элементов в форме) каждого типа запроса на согласование
- Гибкий ACL
- Настраиваемый каждым пользователем поиск заявок по различным наборам параметров. Параметрами могут быть любые свойства шаблонов заявки с возможностью выбрать условие, которое необходимо наложить на данное поле при фильтрации. При этом можно создать сколько угодно сетов для фильтрации. Удобно для быстрого поиска в разных разрезах
- Проверка на валидность введенных значений на основании заданного шаблона для конкретного поля заявки
Не обошлось конечно и без «курьезов».
В итоге мы нашли компромисс — архитектуру решения и реализацию воркфлоу оставили древовидной, а вот использование с точки зрения конфигурирования закрепили на уровне “договоренности”. И правильно сделали. Так как уже сейчас, при анализе задач, связанных с запуском новых типов согласований стало ясно, что на некоторых этапах, для специфических типов заявок, нам необходимо предоставить возможность выбора согласующему различных действий.
Теперь немного о нашем “ноу-хау” (по крайней мере мы в это верим). Чтобы добиться линейности и при этом возможности использовать один воркфлоу для одной схемы согласования (под схемой я имею ввиду сущности, для согласования которых требуется вовлеченность и порядок разных ролей — договор, счет на оплату и т.п.), мы продумали и реализовали механизм условий пропуска очередного этапа (-ов) согласования. В формировании условий мы можем использовать любую сущность карточки согласования и сравнить ее с “чем-либо”.
К примеру, есть у нас следующие сущности: Инициатор, Cумма, Валюта, Контрагент. И нам нужно, чтобы при сумме, меньшей 100 000 руб. не проходило согласование через сотрудника A, при валютных платежах, обязательно подключался к согласованию B, а в случае, если инициатором является сотрудник C, необходимо дополнительное согласование сотрудника D. При этом под сотрудниками мы подразумеваем как отдельных лиц, так и определенную группу. Для реализации этих моментов мы добавляем все точки согласования “в линию”. Т.е.: Инициатор->A->B->D->…
Далее формируются условия на “пропуск” перехода в каждую из точек согласования. К примеру на Переход Инициатор->A конфигурируется условие “Сумма < 100 000”, на (Инициатор)A->B – Валюта = “Рубль”, (Инициатор, A, B)->D – Инициатор != C.
Почему указаны в скобках переходы? Потому что условия могут выполняться в комплексе и “под капотом”, если у нас формируется условие на переход в точку согласования, мы автоматически генерируем еще системный переход, который “обходит” данную точку (вот тут нам помогла наша древовидная архитектура воркфлоу и не пришлось ничего “костылить”).
Ну и немного дегтя в бочку меда. У нас не дошли руки до реализации конфигурируемого механизма управления оповещениями. Хотя изначально его закладывали в архитектуру проекта. Как обычно, для ускорения процесса запуска пришлось немного “временно захардкодить”, и на текущий момент данный хардкод остался. А идея была в том, чтобы создать механизм, аналогичный jira, который позволяет создать свою схему нотификаций, в которой можно задавать триггеры(события) и связывать их с группами или конкретными сотрудниками и иметь возможность ее “привязать” к любому типу заявки.
Для ускорения процесса запуска пришлось немного «временно захардкодить».
Интерфейсы
Немного интерфейсов нашей системы, чтобы было понимание, о чем вообще шла речь
Дашборд
Первое, что видит пользователь системы при ее открытии (если не учитывать процесс аутентификации) – это дашборд. В нем отображаются только активные (незавершенные) согласования. При этом заявки разделены на 2 сегмента:
- Заявки, которые требуют согласования пользователем (я исполнитель)
- Заявки, которые были инициированы пользователем (я автор)
Создание новой заявки
Интерфейс создания новой заявки может иметь представление (количество и расположение элементов) совершенно любое. Здесь представлен простой интерфейс, который демонстрирует возможность ввода чисел, выбор из списка, флаг (чек-бокс), дата, аттачи.
Единственное, на что можно обратить внимание, это опция “Создать еще”. При ее активации, после создания текущей заявки, мы попадаем не в дашборд или в карточку только что созданной заявки, а сразу открывается форма создания новой заявки того же типа, что и только что созданная. Реализовано было по просьбе наших сотрудников, которым приходится “пачками” создавать однотипные заявки.
Этап согласования
XV Международная студенческая научная конференция Студенческий научный форум — 2023
МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССА СОГЛАСОВАНИЕ ДОГОВОРА С КЛИЕНТОМ
Горбатов Д.А. 1
Работа в формате PDF
Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке «Файлы работы» в формате PDF
Бизнес-процессы — любые операции внутри компании, которые помогают решать бизнес-задачи и зарабатывать. Моделирование бизнес-процессов — описание этих операций и документирование требований к ним.
Ответственные за моделирование разбираются в процессах компании и описывают, кто, что и как делает. Изучают каждую операцию и разбивают её на этапы. Сначала описывают всё это текстом, затем превращают описание в схему.
В профессиональном моделировании бизнес-процессов часто используют нотации. Нотация — это набор правил для графического описания бизнес-моделей. Нотации описывают:
какие иконки использовать в моделировании и как их читать;
как отображать последовательность действий в процессе и отношения внутри него;
какие элементы обязательно нужно включить.
Нотации нужны для того, чтобы любой человек понимал, что изображено на схеме. Даже если пользователь видит её впервые, он должен разобраться.
Специалисты придумали много вариантов нотаций. Их делят на две основные категории[1]:
Структурные. Они показывают элементы процесса и взаимосвязи между ними. Это нотации стандарта IDEF: IDEF0, IDEF1x, IDEF4, IDEF5.
Динамические. Они показывают логику выполнения процессов, последовательность и варианты их использования. Это нотации DFD, e EPC, BPMN.
Для моделирования данного бизнес-процесса использовалась нотация eEPC .
Особенностью нотации eEPC является использование событий до и после каждой операции процесса, наличие логических операторов и визуальное представление потоков документов (информации) на схеме. Рассмотрим преимущества и недостатки нотации eEPC.
простота и понятность для исполнителей;
возможность отображения потока объектов (документов) со статусами;
адекватное межпроцессное взаимодействие (процессные интерфейсы);
возможность корректной имитации.
ресурсоемка при моделировании + размер диаграммы;
устарела с точки зрения автоматизации.
Диаграммы в нотации eEPC всегда занимают намного больше места, чем диаграммы в нотациях «Процедура» и BPMN. Кроме того, моделирование в eEPC занимает в несколько раз больше времени, чем в других нотациях.
Нотация eEPC имеет весьма ограниченную семантику. Это приводит к тому, что для сложных практических случаев приходится искать обходные пути для того, чтобы показать нужные аспекты на диаграмме.
В тоже время диаграмма в нотации eEPC является вполне понятной большинству сотрудников. На ней можно отобразить потоки документов, причем со статусами. Можно использовать значок процессного интерфейса для интеграции с другими диаграммами в рамках общей модели компании.
Важным плюсом нотации eEPC является возможность корректной имитации процессов. Полученные расчеты можно использовать для анализа процесса и обоснования действия по его оптимизации [2].
Моделировать бизнес-процессы можно с помощью различных компьютерных инструментов: Bizagi Process Modele, Intalio BPMS, ARIS Express и т. п. Это упрощает создание, управление моделями, отслеживание изменений в них и сокращает время проведения анализа [3].
Одной из самых известных и часто используемых программ моделирования бизнес-процессов является программный продукт ARIS из семейства инструментов CASE — ΑRIS ΕXPRESS — бесплатный инструмент бизнес-моделирования, позволяющий решать основные задачи по созданию моделей бизнес-процессов, блок-схем, инфографических моделей и диаграмм ИТ-инфраструктуры.
Программный продукт ARIS Express (рус. АРИС Экспресс) от разработчика Software AG предназначен для создания базовых бизнес-моделей и является отличным инструментом для решения задач по моделированию бизнес-процессов. Его «старший брат» ARIS Platform (рус. АРИС Платформ) в сравнении со своей бесплатной версией предоставляет более широкий спектр услуг: администрирование, отчётность и аналитику, а также многопользовательский доступ. Наряду с инструментом разработчик предлагает детальную информацию для обучения моделированию ARIS на базе сообщества.
Система ARIS Express отвечает следующим требованиям [4]:
Организационная структура. Программное обеспечение предлагает нотацию и соответствующие объекты (организационная единица, роль и человек) для графического представления отношений между отдельными организационными единицами, такими как отделы или сотрудники.
Бизнес-процессы. Программа позволяет создавать модели бизнес-процессов и рабочих процедур, используя нотацию из семейства ARIS, а также нотацию BPMN. Инструмент также позволяет создавать технологические карты.
Инфологические модели и модели данных. Используя нотацию для моделирования, пользователь может создавать разнообразные модели данных в системе с различным уровнем детализации.
Системные модели. ARIS Express позволяет разработать системную модель, раскрывающую структуру ИТ-систем и их технологические свойства (операционные системы, пользовательские интерфейсы или системы управления базами данных), на которых основаны ИТ-системы.
ИТ-инфраструктура. Возможно создание схем ИТ-инфраструктуры, используемых для моделирования технической коммуникационной инфраструктуры компании. ИТ-системы и принадлежащие им аппаратные системы на схеме могут быть соединены сетями с использованием различных сетевых устройств.
Объектом моделирования данной работы является согласование договора с клиентом.
Для большинства компаний, работающих с клиентами, важно заключать договор с клиентом, чтобы задокументировать требования заказчика. Задачей работы было отслеживание этапов согласования договора с клиентом. Обычно процесс согласования договора с клиентом проходит следующим образом.
Когда вы отправляете контрагенту типовую форму вашего договора, то исхода может быть всего 3: 1. Форма всех устраивает, работаем по ней. Это типовой случай. Менеджер самостоятельно занимается подготовкой документов, руководителю относит лишь бумажный вариант на подпись; 2. Контрагент предлагает свою форму.
В этом случае важно, чтобы форма договора была проверена не менеджером, а ответственным сотрудником. Как правило, это руководитель отдела продаж, директор или юрист. В зависимости от условий договора транслируется решение на менеджера – согласуем договор, отправляем на корректировку или отказываемся работать по таким условиям; 3. Контрагент предлагает корректировки к вашей форме. В случае любой корректировки менеджеру следует составить протокол
разногласий и предоставить его руководителю на согласование. Если
руководство согласно на такие условия работы, то договор с листом
отправляется контрагенту, если нет – лист корректировок пополняется
новыми; 4. Помещение подписанного договора в архив [5].
На рисунке 1 представлена EPC диаграмма бизнес – процесса согласования договора с клиентом.
Рисунок 1 – eEPC диаграмма бизнес – процесса согласования договора с клиентом
Данная модель содержит [6-7]:
Л огический элемент XOR (Исключающее «или») – Строгая дизъюнкция –
О бъект «бизнес – роль» – Роль; объект для определения группы лиц со схожими функциональными обязанностями –
О бъект «бизнес – функция» (действие) – Объект служит для описания процедур, функций или работ –
О бъект «Документ» – Объект используется для отображения на диаграмме электронных документов, сопровождающих выполнение процесса –
О бъект «Событие» – Состояние системы, процесса, влияющее на выполнение процесса или управляющее им –
Список используемых источников
Источник: scienceforum.ru