Для чего предназначены задачи на свободное согласование

Обновлено: 16.06.2024

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

å tp = t или å tp = K * t (7), где

åtp – длительность организационной операции, с

τ – такт потока, с

Κ – кратность (количество рабочих, занятых на выполнении одной организационной операции - целое число)

Установлено, что отклонение расчетной затраты времени на выполнение организационной операции от такта может составлять +/-5% для потоков со строгим ритмом, +/-10% для потоков со свободным ритмом. Эти отклонения называются основными условиями согласования (ОУС). Опыт работы предприятий по внедрению высокопроизводительного оборудования показывает, что эти отклонения могут быть установлены в зависимости от конкретных условий производства.

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

(0,9 ÷ 1,1); (0,9 ÷ 1,15); (0,9 ÷ 1,2); (1,0 ÷ 1,2)

ОУС для потоков со строгим ритмом Σtp = (0.95 ÷ 1.05)* t*Κ (8)

ОУС для потоков со свободным ритмом Σtp = (0.9 ÷ 1.1)* t*Κ (9)

Пример:

Рассчитать основные условия согласования для агрегатно – группового потока мощностью 288 ед.

ОУС Σtp=(0.9 ÷ 1.1)*τ*Κ

при К=1 Σtp=0,9*100*1 ÷ 1,1*100*1=90 ÷ 110

К=2 Σtp=0,9*100*2 ÷ 1,1*100*2=180 ÷ 220

К=3 270 ÷ 330

К=4 360 ÷ 440 и т.д.

Пример:

Будет ли соблюдено ОУС, если время организационной операции 390 с, а мощность конвейерного (со строгим ритмом) потока 180 ед/см?

τ=R/M=28800/180=160 с

ОУС Σtp=(0.95 ÷ 1.05)*τ*Κ

при К=1 152 ÷ 168 (с)

К=2 304 ÷ 336 (с)

К=3 456 ÷ 504 (с)

Так как длительность организационной операции (390 с) не попадает в допускаемые границы отклонений, ОУС для данной операции не будет соблюдено.

Пример:

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

τ=R/M=28800/120=240 с

ОУС Σtp=(0.9 ÷ 1.1)*τ*Κ

при К=2 Σtp мах=1.1*τ*Κ =1,1*240*2=528 с

Особенности расчета основных условий согласования многомодельных потоков со свободным ритмом

Для многомодельного потока с цикличным запуском

Σ t p_A+Σtp_Б+Σtp_B=(0.9 ÷ 1.15)* τ ср*С*Κ, (10), где

: Σtp_A, Σtp_Б, Σtp_B – затраты времени на выполнение операций по моделям цикла А,Б,В, c

τср – средний такт потока,с

С – цикл согласования

К – кратность операций

Для многомодельного потока с последовательным запуском

Σtp.A=(0.9 ÷ 1.15)*τ_А*К при ΔТ от 5 до 15% (11)

Σtp.Б=(0.9 ÷ 1.15)*τ_Б *К

Σtp.B=(0.9 ÷ 1.15)*τ_В *К, где

Σtp._A, Σtp._Б, Σtp_B – затраты времени на выполнение операций по каждой модели А, Б, В, c

τ._А, τ._Б, τ._В – специализированные такты потока по каждой модели, с

К – кратность операций

Σtp_A=Σtp_Б=Σtp_B=(0.9÷1.15)* τ ср*С*Κ при ΔТ до 5% (12)

τ ср=Тср/N или τ ср=R/M общ (13)

Примеры решения задач

Пример:

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

Т А =4,4 час Т Б =4,2 час Т В =4,11 час

Рассчитать данные предварительного расчета потока

Т А = 4,47 час Для определения вида запуска необходимо

Т Б = 4,2 час определить разницу в трудоемкости моделей. Для

Т В = 4,11 час этого трудоемкость любой модели принимаем за

N = 79 рабочих 100%, а трудоемкости двух других выразим через

ОУС, М, τ, L п.л. трудоемкость этой модели.

Sп. Кр.м.

Пусть трудоемкость модели В Т В=100%

Т Б=4,2/4,11*100=102,19% ΔТ=2%

Т В=4,4/4,11*100=107,06% ΔТ=7%

Так как разница в трудоемкости моделей ΔТ 2

ОУС для данного вида запуска

Σtp_A=(0.9÷1.15)*τ_А *К

Σtp_Б=(0.9÷1.15)*τ_Б *К

Σtp_B=(0.9÷1.15)*τ_В *К

для К=1 Σtp_A=180,5÷230,6 (с)

Σtp_Б=172,3÷220,1 (с)

Σtp_B=168,6÷215,4 (с) и. т.д

Пример:

Определить основные условия согласования агрегатного потока с цикличным запуском моделей. Сменный выпуск модели А – 60 ед. , модели В – 120 ед. (для двух рабочих).

М _А=60 ед. (А=1) Σtp_A +Σtp_B=(0.9÷1.15)*τц *Κ

М _В=120 ед. (В=2) τц=τср*С

К=2 С=А+В=1+2=3

ОУС -? τср=R/Mобщ, Мобщ= М _А + М _В=180 ед

τср=28800/180=160 с

τц=160*3=480 с

ОУС при К=2 Σtp_A +Σtp_B=(0.9÷1.15)*480*2=864÷1104 (с)

© 2014-2021 — Студопедия.Нет — Информационный студенческий ресурс. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав (0.006)

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

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

Процесс согласования в 1С: Документооборот

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

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

Отличие электронного от бумажного согласования

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

Согласование документов вручную

В традиционной бумажной версии процедура выглядит так:

• Юрист направляет проект ответственным работникам;
• Каждый сотрудник вносит в документ свои правки;
• Несколько раз исправленный текст возвращается на доработку;
• Новая редакция повторно отправляется на согласование;
• Процесс повторяется до принятия единого решения всеми участниками.

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

Электронный вариант согласования документов

В программе 1С: Документооборот согласование договора выглядит следующим образом:

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

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

Порядок согласования документов

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

Настройка модуля согласования документов

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

• Администраторы;
• Новая группа в профиле с ролью «Согласование (настройка).

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

Виды программной связи документов

Типовой функционал программы 1С: Документооборот способен отслеживать несколько десятков согласований к одному документу. Сложное переплетение взаимоотношений можно автоматизировать. Для этого классифицируют типы связей при обработке документа:

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

Обзор процессов согласования документов

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

Ход согласования документов

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

Рассмотрение

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

Согласование

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

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

Детали работы

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

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

Шаблоны согласований

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

• сотрудник создает документ-заявку;
• согласует заявку руководитель данного сотрудника;
• руководитель ИТ-службы согласует документ;
• исполнитель ИТ-службы направляет уведомление автору заявки об ее выполнении.

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

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

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

Контроль процессов

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

• спискам документов;
• затраченному времени;
• статистике циклов и результатов.

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

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

Анализ и мониторинг согласований документов

Автоматическая служба 1С: Документооборота отслеживает более 100 показателей процессов согласований. Основные из них:

• число циклов;
• количество просроченных задач;
• время просрочки;
• средние трудозатраты.

Устанавливается пороговое значение роста или снижения показателей согласования. Программа информирует о достижении нижнего критического значения.

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

Заключение

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

Как настроить согласование

Все настройки выполняются на 3 вкладках: Основное, Время выполнения и Переходы. Вы можете определить тип и логику согласования, указать название задачи, установить крайний срок и т.д.

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

Убедитесь, что в контекст процесса добавлена переменная, ссылающаяся на объект согласования.

На вкладке Основное представлена общая информация о задаче согласования:

• Название * — введите текст, который будет отображаться на схеме процесса. Рекомендуем давать краткое и емкое название, чтобы процесс легко читался.

• Название задачи * — текст, введённый в этом поле, исполнитель увидит в списке задач или на карточке задачи. Вы можете добавить в название контекстные переменные, чтобы создать более детальное описание. Для этого нажмите на значок + в правом углу поля.

• Что отправляем на согласование * — укажите контекстную переменную, ссылающуюся на файл или приложение.

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

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

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

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

Рассмотрим работу юридического отдела. Любой сотрудник может проверить содержание договора на соответствие нормам закона и спрогнозировать правовые последствия заявленных условий. Не имеет значения, кто именно будет заниматься согласованием, существенно лишь, чтобы задача была выполнена максимально быстро. В этом случае нужно воспользоваться опцией Параллельное согласование , но при этом в настройках переходов установить процент согласования и отказов больше нуля. Задача придет каждому сотруднику юридического отдела, и тот, кто менее загружен в данный момент, сможет сразу приступить к выполнению. Как только ELMA365 получит подтверждение, что резолюция вынесена (для этого нужно нажать на кнопку Согласовано или Отклонено в карточке задачи), система отменит задачу для других сотрудников. Подробнее о настройках переходов можно почитать ниже.

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




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

Задать срок выполнения задачи можно двумя способами:

• Точное время — укажите за сколько минут, часов или дней исполнитель должен выполнить работу. Срок выполнения можно указывать с учетом настройки рабочего календаря;

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

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

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

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




В поле Прервать определите, каким будет следующий шаг в процессе, если исполнитель не успеет завершить согласование до установленного времени.




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




Это поможет вовремя отреагировать на ситуацию и принять необходимые меры.




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

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

Чтобы открыть окно с настройками перехода, нажмите на его название.




• Название — мы рекомендуем давать короткое и понятное название, так как оно будет отображаться на схеме процесса;
• Описание — в этом поле введите описание перехода.




• Связка — это логическая операция, которая используется для проверки нескольких условий. Если результат проверки Истина , то процесс продолжается по данному переходу:
  • И — результат Истина , если выполняются оба условия;
  • ИЛИ — результат Истина , если выполняется хотя бы одно условие;
  • И НЕ — результат Истина , если хотя бы одно условие не выполнено;
  • ИЛИ НЕ — результат Истина , если оба условия не выполнены.

  Обратите внимание, что условия проверяются в том порядке, в котором они перечислены в настройках перехода.

  • Операнд 1, 2 — в этом поле вы указываете переменную из контекста процесса или определенное значение, например, процент согласования или процент отказов.
  • Операция — здесь задается оператор сравнения для проверки конкретного условия.

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

  
  

  Доступны следующие настройки:

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

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

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

  Для наглядности рассмотрим настройку переходов на примере маршрута согласования договора.

  Ниже перечислены все шаги процесса и их исполнители:

  
  

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

  У первой задачи Согласовать договор есть четыре исходящих перехода:

  • Согласовано,
  • Отклонено,
  • Переход по умолчанию без названия,
  • Контролировать согласование (на схеме изображается со значком часов).

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

  • Переход Согласовано. Для начала настроим переход Согласовано . Если в условиях перехода мы укажем процент согласования > 0, то как только кто-то нажмет Согласовать , система отменит задачу для всех остальных согласующих, и процесс перейдет к следующему шагу (Согласование с руководителем отдела продаж).
  • Переход Отклонено . Аналогичным образом настраивается переход Отклонено (процент отказов >0). Если кто-то из юристов посчитает, что текст договора недостаточно проработан или не соответствует требованиям законодательства, он откажет в согласовании. После этого инициатору придет задача Корректировать договор , а задача согласования будет отменена для других юристов. Вот как выглядят настройки перехода:

  
  

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

  Вторая задача Согласовать договор расположена в зоне ответственности с одним исполнителем. Это значит, что к ней не применяется настройка параллельное или последовательное согласование.

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

  Нашли опечатку? Выделите текст, нажмите ctrl + enter и оповестите нас

  
  

  Продолжаем рассказывать о том, как мы улучшаем жизнь не только нашим клиентам и партнерам, но и сотрудникам компании. Речь пойдет о внедрении системы согласования. Сознательно не указал согласования “чего”, так как в дальнейшем станет понятно, что чисто теоретически, согласования “всего”.
  
  

  Размышления о системе согласований

  Изначально в нашей компании, как и во многих других, в которых мне пришлось поработать, а также в которых был “гостем” или просто наслышан от своих знакомых, согласование договоров велось (и на момент написания статьи пока еще ведется), посредством обычной переписки в почте. Естественно это устраивает компании с небольшим количеством персонала и контрагентов. Нет особой необходимости придумывать и внедрять системы из-за подписания одного-двух договоров в месяц (а то и год) с единолично принимающим о подписывании решении генеральным директором. Аналогичная ситуация наблюдалась и с оплатой счетов. Каждый сотрудник, который взаимодействует с контрагентами и которому необходимо что-то оплатить, запрашивает счет и по почте отправляет в бухгалтерию с просьбой “оплатить”. При этом, далеко не всегда бухгалтерия оплачивает счета без предварительного согласования оплаты с непосредственным руководителем сотрудника и/или руководством компании. При определенных условиях цепочка согласований может “укорачиваться” или наоборот “удлиняться”.

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

  Наши хотелки

  У нас были свои минимальные требования к системе:

  • User-friendly интерфейс и крайне желательно web-ориентированный (без надобности установки клиентов)
  • Гибкость настройки
  • Мы хоть и не клинические, но параноики. Поэтому сервисы, в которых может появляться конфиденциальная информация, хотим держать в нашем закрытом периметре

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

  Реализация

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

  Единственное, над чем пришлось нам поломать копья — это в процессе разработки архитектуры не поддаться на соблазн удовлетворить требования “как есть”, в ущерб гибкости и дальнейшему удобству эксплуатации. Соблазн был велик, особенно у основного заказчика, так как срок реализации и внедрения сокращался бы в 2 раза. Но нам удалось убедить и руководство, и себя, что “лучше день потерять, потом за 5 минут долететь”. И считаю, что мы сделали правильный выбор.
  

  • Один воркфлоу — разные участники согласования (связан со следующим пунктом)
  • Условия пропуска этапа согласования по заданным условиям (любое поле в заявке можно добавить в условие с заданной проверкой и на основании валидности условия определяется необходимость перехода на очередной шаг согласования или его “пропуск”)
  • Наш “фирменный” интерфейс
  • Задание дефолтных значений справочников (как пользовательских, так и системных). Пользовательский справочник — это сущность, позволяющая задавать элементы самостоятельно пользователем. Созданные элементы будут доступны только ему. При этом в такой справочник администратор системы может внести общие элементы, которые будут доступны всем пользователям системы
  • Определение наиболее часто использующихся элементов справочников для каждого пользователя и формирование списков в интерфейсе исходя из данной статистики (сортировка)
  • Полностью настраиваемые из админки схемы (структура и свойства полей для заполнения) и представления (расположение элементов в форме) каждого типа запроса на согласование
  • Гибкий ACL
  • Настраиваемый каждым пользователем поиск заявок по различным наборам параметров. Параметрами могут быть любые свойства шаблонов заявки с возможностью выбрать условие, которое необходимо наложить на данное поле при фильтрации. При этом можно создать сколько угодно сетов для фильтрации. Удобно для быстрого поиска в разных разрезах
  • Проверка на валидность введенных значений на основании заданного шаблона для конкретного поля заявки

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

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

  К примеру, есть у нас следующие сущности: Инициатор, Cумма, Валюта, Контрагент. И нам нужно, чтобы при сумме, меньшей 100 000 руб. не проходило согласование через сотрудника A, при валютных платежах, обязательно подключался к согласованию B, а в случае, если инициатором является сотрудник C, необходимо дополнительное согласование сотрудника D. При этом под сотрудниками мы подразумеваем как отдельных лиц, так и определенную группу. Для реализации этих моментов мы добавляем все точки согласования “в линию”. Т.е.: Инициатор->A->B->D->…

  Далее формируются условия на “пропуск” перехода в каждую из точек согласования. К примеру на Переход Инициатор->A конфигурируется условие “Сумма B – Валюта = “Рубль”, (Инициатор, A, B)->D – Инициатор != C.

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

  Ну и немного дегтя в бочку меда. У нас не дошли руки до реализации конфигурируемого механизма управления оповещениями. Хотя изначально его закладывали в архитектуру проекта. Как обычно, для ускорения процесса запуска пришлось немного “временно захардкодить”, и на текущий момент данный хардкод остался. А идея была в том, чтобы создать механизм, аналогичный jira, который позволяет создать свою схему нотификаций, в которой можно задавать триггеры(события) и связывать их с группами или конкретными сотрудниками и иметь возможность ее “привязать” к любому типу заявки.
  

  Интерфейсы

  Немного интерфейсов нашей системы, чтобы было понимание, о чем вообще шла речь

  Дашборд

  
  

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

  • Заявки, которые требуют согласования пользователем (я исполнитель)
  • Заявки, которые были инициированы пользователем (я автор)

  Создание новой заявки

  
  

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

  Этап согласования

  
  

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

  1. Вместо кнопок создания появляются кнопки, клики на которые переводят заявку в одно из состояний бизнес-процесса. В вырожденном случае, о чем писал выше, это “Отклонить” и “Согласовать”
  2. Вложения, комментарии и новая сущность журнал (история действий) вынесены в отдельные вкладки
  3. По умолчанию все поля заявки, кроме комментария – недоступны для редактирования. При этом мы заложили функциональность, позволяющую предоставить на любом конкретном шаге согласования возможность корректировать только заданный набор полей.
  4. Если вы являетесь инициатором заявки (вы всегда можете зайти в карточку согласования), и у вас появляется опция “Создать дубликат”, при клике на которую открывается форма создания заявки, значения полей которой (за исключением вложений) дублируют значения полей текущей заявки.

  
  

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

  Поиск

  
  

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

  Администрирование бизнес-процесса

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

  • Кто является согласующим в данной точке
  • Разрешения на выполнение действий в заданной точке маршрута
  • Условия пропуска данной точки (этапа согласования)

  Согласующие

  
  

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

  Разрешения на действия

  
  

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

  • Загрузка вложений
  • Просмотр вложений
  • Комментирование
  • Изменение значений полей заявки

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

  Условия пропуска

  
  

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

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

  Вместо заключения

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

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

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

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

    
  • Связаны ли права человека с нравственностью и экономическим развитием страны
    
  • Существует ли в россии лишение гражданства а оно ограничено б оно отменено в существует
    
  • Когда разблокируют кредитную карту сбербанка после погашения задолженности
    
  • Рекомендации по предупреждению преступных посягательств в отношении детей что должен знать ребенок
    
  • Кому смертную казнь заменили ссылкой по ходатайству великого князя михаила павловича