Разное

Схемы документооборота: Схемы документооборота. По документообороту встречают Пример схемы документооборота

21.04.1970

Содержание

отправка и получение документов — ГК ЛАД Москва, Нижний Новгород, Казань

Отправка и получение любого электронного документа в СБИС состоит из следующих этапов:

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

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

Регламент обмена документами с контрагентами

В СБИС есть четыре основных регламента обмена электронными документами между контрагентами. Они помогают организовать большинство бизнес-­процессов:

  • Утверждение договора
    Регламент прохождения согласования имеет стандартный вид.
    Документ утверждается двумя сторонами.
  • Утверждение счетов-­фактур и других документов реализации
    Процедура выставления и получения счетов-­фактур в электронном виде строго регламентирована. Она подробно расписана в Приказе Минфина РФ 50н. Отличия связаны с наличием дополнительных технических документов — они нужны для подтверждения даты отправки и получения счетов-­фактур.
  • Сверка взаиморасчетов с контрагентами
    Основное отличие от типового согласования состоит в том, что при обнаружении расхождения получатель сможет отправить свою редакцию акта сверки. Приняв вариант второй стороны инициатор по общим правилам исправляет документ и направляет новую версию акта сверки.
  • Обмен корреспонденцией
    Различные документы, такие как дополнения к договору, пояснительные записки, поздравительные открытки, можно отправлять и принимать без согласования.

Шпаргалка делопроизводителя : Документооборот в организации

ГОСТ Р 7.0.8–2013. Система стандартов по информации, библиотечному и издательскому делу. Делопроизводство и архивное дело. Термины и определения расшифровывает понятие документооборота как движение документов внутри организации с момента их создания и получения до завершения исполнения или отправки.

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

Что можно сделать для упрощения документооборота?

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

    10 причин внедрить электронный документооборот>>

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

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

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

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

Виды документопотоков

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

    Схема движения входящих документов внутри организации

  • Исходящие документы. Основная масса исходящих — это ответы на входящие документы, а также запросы в другие организации, направление отчетности в государственные органы.

    Схема движения исходящих документов внутри организации

  • Внутренние документы. Это организационно-распорядительные документы — приказы, распоряжения, протоколы; информационно-справочные документы — служебные и докладные записки.

    Схема движения внутренних документов организации

Как рассчитать объем документооборота?

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

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

При подсчете нужно учитывать внутренние документы, копии документов.

Схема выставления электронных счетов-фактур, новая концепция ЭДО от ФНС

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

Что изменится с 1 июля 2021 года

С 1 июля утратит силу приказ Минфина России от 10 ноября 2015 года № 174н, который регламентирует способы выставления и получения электронных счетов-фактур. Вместо него вступит в силу новый Порядок. Сейчас счета-фактуры можно выставлять в бумажном и электронном виде. Использование электронной формы возможно только в том случае, если есть техническая возможность, и стороны договорились об электронном документообороте. С 1 июля выставление счетов-фактур по прослеживаемым товарам предусмотрено только в электронном виде. Исключение составляют сделки с физлицами и экспорт товаров.

С 1 июля нельзя будет шифровать счета-фактуры в следующих случаях:

  • когда нормативными правовыми актами запрещено шифрование информации счетов-фактур;

  • когда счёт-фактура выставляется по прослеживаемым товарам и содержит регистрационные номера партии товара;

  • если по договору с продавцом или покупателем оператор ЭДО проверяет электронные счета-фактуры, в том числе на соответствие утверждённому формату.

Новая схема выставления электронного счёта-фактуры

В целом алгоритм выставления электронного счёта-фактуры изменился незначительно.

  • Продавец формирует электронный документ и отправляет покупателю через своего оператора ЭДО.

  • Оператор отправляет продавцу уведомление о том, что файл принят, не содержит технических ошибок и дошёл до покупателя.

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

  • Если счёт-фактура содержит ошибки, покупатель формирует уведомление об уточнении. Продавец переоформляет документ и направляет его покупателю, процедура повторяется.

Из новшеств можно выделить следующее:

  • продавец и покупатель не должны сами формировать дополнительный служебный документ-извещение о получении подтверждения оператора ЭДО;

  • продавец, выставляющий счёт-фактуру, не должен проверять действительность усиленной УКЭП лица, уполномоченного его подписывать;

  • оператор ЭДО по договору с продавцом может проверять правильность электронного счёта-фактуры и его подписи и в случае отрицательного результата направлять в адрес продавца сообщение об ошибке.

Возможные схемы выставления электронных счетов-фактур

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

В частности, электронные документы будут регистрироваться в системе оператора ЭДО. Оператор будет присваивать каждому документу регистрационный номер. По РНД можно будет найти документ и посмотреть все действия над ним: подписание, аннулирование, редактирование и т.д.

Электронный счёт-фактура

Предполагается, что алгоритм выставления электронного счёта-фактуры будет таким:

  • Контрагент 1 создаёт электронный документ, подписывает его электронной подписью и регистрирует у оператора ЭДО. Оператор присваивает ему РНД.

  • Контрагент 1 передаёт этот документ контрагенту 2 любым удобным способом: по электронной почте, в мессенджере, на флэшке или через систему электронного документооборота.

  • Контрагент 2 получает документ и проверяет его по РНД, обратившись к оператору ЭДО.

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

Обменивайтесь электронными документами с контрагентами через систему ЭДО «Астрал.ЭДО». Новый сервис поддерживает работу с любой электронной подписью и бесплатный роумингбез дополнительных настроек.
Электронный корректировочный счёт-фактура

Схема выставления корректировочного документа разработана по аналогии с алгоритмом выставления первичного счёта-фактуры. Контрагент 1 таким же образом регистрирует КСФ у своего оператора ЭДО, получает РНД и направляет документ контрагенту 2 любым удобным способом. Связывание документов происходит на стороне хозяйствующих субъектов и ФНС, а не оператора ЭДО.

Первичка, требующая подписания двумя сторонами

Концепция предусматривает следующий порядок действий над такими документами:

  • Контрагент 1 формирует и подписывает документ своей ЭП, а затем направляет его контрагенту 2.

  • Контрагент 2 проверяет документ, при отсутствии замечаний подписывает его своей ЭП и направляет обратно. Каким образом происходит обмен — выбирают сами хозяйствующие субъекты.

  • Для документов, которые будут дополнительно определены соответствующими НПА, будет введена обязательная регистрация подписанного с обеих сторон документа у оператора ЭДО. Обязанность по регистрации возлагается на контрагента 1. В результате документ получает РНД и при необходимости направляется в ФНС.

Первичка, требующая подписания тремя сторонами

К такому виду документов относится, например, транспортная накладная. Её будут оформлять по следующей схеме:

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

  • Перевозчик подписывает транспортную накладную со своей стороны и направляет оператору ЭДО, который присваивает РНД1 и направляет его перевозчику.

  • Перевозчик направляет подписанную двумя подписями ТН в адреса грузоотправителя и грузополучателя.

  • Грузополучатель подписывает ТН со своей стороны и направляет оператору ЭДО для регистрации конечного документа. Оператор присваивает РНД2 и направляет его грузополучателю.

  • Грузополучатель пересылает подписанную тремя сторонами ТН грузоотправителю и перевозчику.

Если обмен ТН осуществляется участниками через оператора ЭДО, то ее регистрация выполняется автоматически. На схеме выполняются одновременно пункты 2 и 3, а также 4 и 5.

Для обмена электронными документами с контрагентами необходима усиленная квалифицированная электронная подпись. «Aстрал-ЭТ» — надёжная и безопасная ЭП, которая подойдёт для электронного документооборота, а кроме того для участия в торгах, сдачи отчётности и работы с госпорталами.

Схема — документооборот — Большая Энциклопедия Нефти и Газа, статья, страница 1

Схема — документооборот

Cтраница 1


Схема документооборота ( СД) устанавливает перечень входных и выходных документов, источник поступления и адресат, периодичность составления для отдельных подразделений системы управления.  [2]

Схема документооборота при расчетах переводом по поручению клиентов отличается простотой. Именно поэтому при данной форме в первую очередь появлялись нововведения.  [3]

Схема документооборота ( СД) устанавливает перечень входных и выходных документов, источник поступления и адресат, периодичность составления для отдельных подразделений системы управления.  [5]

Схема документооборота в кузнечном цехе паровозоремонтных заводов приведена на фиг.  [6]

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

Изобразите схему документооборота на предприятии, укажите, какие недостатки в его организации могут отрицательно повлиять на сохранность активов и достоверность финансовой отчетности.  [8]

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

Дальнейшее совершенствование схемы документооборота в ИСОД предусматривает автоматизацию получения первичных ( исходных) документов с помощью технических средств.  [11]

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

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

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

Страницы:      1    2    3    4

ООО «Цифровые технологии»

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

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

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

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

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

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

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

Для защиты от рассмотренных угроз компания «Цифровые технологии» совместно с партнерами предлагает комплексное организационно-техническое решение по созданию защищённого юридически значимого электронного документооборота.

ДЕЙСТВИЯ ОРГАНИЗАТОРА ДОКУМЕНТООБОРОТА

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

Идентификаторы вносятся в сертификаты открытого ключа клиентов документооборота и позволяют контролировать полномочия пользователей на совершение операций с документами в конкретной системе документооборота. OID зарегистрированные в Удостоверяющем центре включаются состав следующих расширений сертификата ключа подписи: Key Usage (использование ключа), Extended Key Usage (расширенное использование ключа), Application Policy (политики применения сертификата).

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

2. Организаторам документооборота можно использовать уже готовые решения, предлагаемые компаниями «Цифровые технологии», «Актив», «Aladdin» в части приобретения необходимого специализированного программного обеспечения и шаблонов организационно-нормативных документов.

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

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

  • Получение и обработку запроса от Администраторов взаимодействия с пользователями на выпуск сертификата или изменение статуса уже выпущенного сертификата с последующей передачей запроса в ЦС.

  • Хранение заверенных запросов и журналов событий в течение установленного срока, предусмотренного регламентом работы системы, в составе которой функционирует УЦ.

  • Резервное копирование на внешние носители локального архива.

Под реализацию данных функциональных возможностей разрабатывался модуль КлиентУЦ в составе ПО «КриптоТри» или «eToken КриптоАРМ». Данный модуль позволяет задавать шаблон атрибутов и расширений с предустановленными значениями, используемый в Мастере создания запроса на сертификат. Для использования защищенного канала между удаленным центром регистрации и центром сертификации можно установить ПО Trusted TLS.

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

ДЕЙСТВИЯ ПОЛЬЗОВАТЕЛЕЙ СИСТЕМЫ ДОКУМЕНТООБОРОТА

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

2. С сайта производителей пользователям необходимо скачать и установить дистрибутив продукта «КриптоТри» («eToken КриптоАРМ»).

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

4. Выпуск сертификата. Он производится посредством обработки запроса на сертификат, полученного в предыдущем пункте. После генерации сертификата сотрудник УЦ записывает пользователю на токен следующие данные:

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

Полное описание решения Вы можете прочесть загрузив файл (967Кб) с “Центра загрузки”.

Пример графика документооборота в организации в 2021 году

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

Кому и зачем нужен график

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

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

  • утери документации;
  • неотражения или несвоевременного отражения в учете фактов хозяйственной жизни;
  • штрафов со стороны контролирующих органов.

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

Кто его формирует

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

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

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

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

Правила составления

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

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

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

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

Образец

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

Приложение №1

К приказу об учетной политике

№1п от 31.12.2019

УТВЕРЖДАЮ:

Генеральный директор ООО «Ppt.ru»

______________________/Петров П.П./

График

документооборота в бухгалтерии

Вид документа и кол-во экз.

Составление

Обработка

Передача в архив

Ответственное лицо

Срок

Ответственное лицо

Срок

Ответственное лицо

Срок

Документы по кассе (ПКО, РКО, объявление на взнос наличными), 1 экз.

Кассир

1 день

Бухгалтер

1 день

Бухгалтер

5 лет (после проверки, ревизии)

Табель учета раб. времени

Начальник склада, начальник отдела продаж, начальник отдела логистики

5-е число месяца

Бухгалтер по расчету з/п

2 раб. дня

Бухгалтер по расчету з/п

5 лет (после проверки, ревизии)

Приказ о направлении в командировку (3 экз.)

Отдел персонала

За 5 дней до даты убытия

Бухгалтер

1 раб. день

Бухгалтер

75 лет

Авансовый отчет

Подотчетные лица

2 раб. дня после прибытия

Бухгалтер

2 раб. дня

Бухгалтер

5 лет (после проверки, ревизии)

Документы на отгрузку (ТН, СФ)

Сотрудник склада

2 раб. дня

Бухгалтер

7 раб. дней

Бухгалтер

5 лет (после проверки, ревизии)

Согласовано:

Заместитель директора: /Сидоров С.С./

Главный бухгалтер: /Викторова В.В./

Ознакомлены:

Начальник склада: /Павлов А.А./

Начальник отдела продаж: /Михайлова Е.В./

Начальник отдела логистики: /Алексеев И.А./

Особое внимание следует уделить срокам хранения. Так, кадровые документы хранятся в архиве не менее 50 лет. При выходе сотрудника на пенсию ПФР иногда запрашивает данные о начисленной заработной плате.

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

Как утвердить

После того как график составлен, издается приказ о его утверждении, в котором руководитель компании ставит свою подпись под грифом «УТВЕРЖДАЮ». Иногда возникает вопрос, утверждается ли график документооборота руководителем организации, если документ составлен для внутреннего документооборота филиала или обособленного подразделения. В этом случае приказ утверждается руководителем филиала или обособленного подразделения. Для обмена документами с головным офисом составляется отдельный приказ.

Образец приказа

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


Документооборот — отдельный фрагмент общей картины

Дмитрий Пинаев

Генеральный директор ГК «Современные технологии управления»

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

С точки зрения специалистов ИТ-службы документы представляют мощный информационный поток, который можно автоматизировать двумя способами. В первом случае прохождением и хранением документов занимаются специализированные системы. Например, прохождение стандартных бухгалтерских документов может автоматизироваться в управленческой информационной системе (1С, Галактика), работа с конструкторско-технологической документацией — в PLM-системе (Лоцман:PLM, T-FLEX DOCs). Но в компании всегда есть набор документов, которые не «ложатся» в одну из существующих информационных систем (ИС). Это могут быть внутренние отчеты, организационно-распорядительная, проектная и другая документация. В этом случае, движение документов может быть автоматизировано только с помощью специализированных систем электронного документооборота с поддержкой технологии workflow (например, OPTiMA-WorkFlow).

Методологию внедрения подобных систем, созданную на основе опыта специалистов ГК «Современные технологии управления» (biztech.ru) (г. Самара), как консультантов по управлению, и специалистов компании Upscale Soft (upscalesoft.ru), осуществляющих разработку и внередние системы «OPTiMA-WorkFlow» (optima-workflow.ru), мы и предлагаем рассмотреть в этой статье.

Формализация документооборота — способ повысить эффективность внедрения СЭД

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

Директор по разработке и внедрению компании UpScale Soft Ефим Старостин так комментирует сложившуюся на ситуацию: «Внедряя OPTiMA-WorkFlow в крупных организациях, мы часто сталкиваемся с проблемой недостаточного понимания важности формализации документооборота, что приводит к различным негативным последствиям, например, к частой переделке маршрутных схем движения документов… В редких случаях мы опираемся на готовые модели бизнес-процессов, созданные на базе систем бизнес- моделирования, благодаря чему резко сокращаются сроки внедрения и возрастает отдача от системы документооборота…»

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

  • Неправильному выбору СЭД, т. к. могут быть неучтены особенности движения документов;
  • К срыву сроков проекта из-за необходимости корректировать неправильно выполненное описание документооборота уже в момент внедрения системы;
  • К провалу проекта из-за не использования сотрудниками неправильно настроенной системы.

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

Подходы к формализации документооборота

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

Описание документооборота «от документов» исторически является наиболее распространенным и широко используется при внедрении СЭД. При таком подходе во главу угла ставится сам документ и его перемещение между исполнителями. Описание маршрута прохождения внутреннего документа, как правило, выглядит следующим образом: Разработка проекта документа — Согласование документа — Доработка документа -Отправка (или Сдача в архив) документа. Причем стадии «Согласование документа» и «Доработка документа» могут повторяться до тех пор пока не будут устранены все замечания.

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

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

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

Применение технологий бизнес-моделирования

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

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

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

  • Анализ и принятие взвешенного решения о способе автоматизации бизнес-процессов компании. Возможными способами могут стать, как уже говорилось выше: автоматизация с помощью управленческой информационной системы, внедрение PLM-системы, системы документооборота или workflow или вообще отказ от автоматизации, если решить задачу можно за счет простого изменения бизнес-процесса;
  • Формирование маршрутов документооборота, на основе содержащейся в модели информации;
  • Разработка технических заданий на внедрение информационных систем с использованием диаграмм бизнес-процессов;
  • Формирование инструкций пользователя по работе с информационной системой путем дополнения бизнес-процессов функциями по работе в ИС (занесение данных в систему, получение отчета, и т. п.). В результате становится возможным получение реестра функций ИС и включение регламента работы с ИС непосредственно в должностные инструкции исполнителей.

Система бизнес-моделирования Business Studio

На сегодняшний день для создания модели деятельности компании целесообразно использовать специализированные системы бизнес-моделирования, позволяющие решать широкий круг задач: описание бизнес-процессов и организационной структуры, создание реестра документов компании, формирование отчетов и регламентных документов, в том числе и отчета по документообороту. Например, в системе бизнес-моделирования Business Studio (businessstudio.ru) описание бизнес-процессов и документооборота происходит одновременно. Если в рамках процесса происходит работа с документом (создание, изменение, использование), то документ указывается с помощью входящей или исходящей из функции стрелки, а исполнитель функции закрепляется автоматически при расположении функции в соответствующей дорожке на кросс-функциональной диаграмме (Рис. 3).

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

Процесс Ответственный Требования к срокам Поступления Передача
Процесс Ответственный Процесс Ответственный
A2.1.1.8 Поставка инструмента Поставщик Согласно условиям договора A2.1.1.9 Получение инструмента и сопроводительной документации. Проверка инструмента на соответствие требованиям Менеджер по инструменту
A2.1.1.9 Получение инструмента и сопроводительной документации. Проверка инструмента на соответствие требованиям Менеджер по инструменту Согласно условиям договора A2.1.1.8 Поставка инструмента Поставщик A2.1.2.1 Формирование приходного материального ордера. Подписание накладной на инструмент Кладовщик
A2.1.2.1 Формирование приходного материального ордера. Подписание накладной на инструмент Кладовщик В течение 20 мин. A2.1.1.9 Получение инструмента и сопроводительной документации. Проверка инструмента на соответствие требованиям Менеджер по инструменту Бухгалтер
A2.1.2.3 Регистрация приходного ордера Бухгалтер В течение одного часа. A2.1.2.1 Формирование приходного материального ордера. Подписание накладной на инструмент Кладовщик
A2.1.2.4 Прием инструмента на склад. Отметка о приеме в журнале учета движения инструмента Кладовщик Не более 20 мин. A2.1.2.1 Формирование приходного материального ордера. Подписание накладной на инструмент Кладовщик

Таблица 1. Регламент прохождения документа «Гарантийный талон», сформированный в системе Business Studio

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

№  Изменения в бизнес-процессах Отражение в документообороте
1 Изменен ответственный за выполнение функции. В маршруте движения документа необходимо изменить исполнителя.
2 Изменена структура бизнес-процесса. Изменился маршрут прохождения документа.
3 Документ перестал использоваться в компании. Исключение документа из документооборота.
4 Появился новый бизнес-процесс, что повлекло за собой появление нового документа.

Разработка и ввод в действие:

  • Формы документа;
  • Маршрута документа.

Таблица 2. Изменения в бизнес-процессах и их отражение в документообороте

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

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

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

Опубликовано по материалам:
Журнал «BYTE / Россия», № 6 2006

Июнь 2006г.

Рекомендуемые материалы по тематике

Программные продукты бизнес-моделирования
Процедура БП
Глоссарий. Реинжиниринг
Процессный подход: верхи хотят, низы…?

Настроить схемы рабочего процесса | Служба поддержки Atlassian

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

Добавление схемы рабочего процесса

  1. Выберите> Проблемы .
  2. В разделе WORKFLOWS щелкните Workflow Schemes .
  3. Щелкните Добавить схему рабочего процесса .
  4. Введите имя и описание новой схемы рабочего процесса.
  5. Щелкните Добавить , чтобы создать новую схему рабочего процесса.

Настройка рабочих процессов для схемы рабочего процесса

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

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

Настройка схемы рабочего процесса, связанной с проектом

  1. Выберите Настройки > Проекты .
  2. Перейдите в свой проект и щелкните Настройки проекта .
  3. Щелкните Workflows , чтобы настроить схему рабочего процесса вашего проекта по мере необходимости.

    Что вы хотите сделать? Шаги
    Добавить рабочий процесс в схему

    1. Щелкните Добавить рабочий процесс и выберите Импортировать из пакета или Добавить существующий .
    2. Выберите требуемый рабочий процесс и типы задач.

    Редактировать рабочий процесс

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

    Удаление рабочего процесса из схемы Щелкните крестик в разделе «Операции», чтобы удалить рабочий процесс из схемы.
    Измените типы задач, связанные с рабочим процессом. 1. Щелкните Assign в разделе Типы задач для нужного рабочего процесса.
    2. В открывшемся диалоговом окне выберите нужные типы задач.
    3. Щелкните Finish .
    Просмотр текстового представления рабочего процесса Наведите указатель мыши на нужный рабочий процесс и щелкните Просмотреть как текст .
    Изменить схему рабочего процесса, связанную с проектом Щелкните Переключить схему рядом с именем схемы. Дополнительные инструкции см. В разделе «Управление рабочими процессами».
  4. Когда вы будете готовы опубликовать рабочий процесс, щелкните Associate , чтобы начать процесс миграции.
  5. Нажмите Подтвердить , и все готово.

Настройка схемы рабочего процесса вне проекта

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

  1. Выбрать> Проблемы .
  2. В разделе WORKFLOWS щелкните Workflow Schemes .
  3. Щелкните Edit для соответствующего рабочего процесса.

  4. При необходимости измените схему рабочего процесса

    Что вы хотите сделать? Шаги
    Добавить рабочий процесс в схему

    1.Щелкните Добавить рабочий процесс и выберите Импортировать из пакета или Добавить существующий .
    2. Выберите требуемый рабочий процесс и типы задач.

    Удаление рабочего процесса из схемы Щелкните Удалить в столбце Операции.
    Измените типы задач, связанные с рабочим процессом. 1. Щелкните Assign в разделе Типы задач для нужного рабочего процесса.
    2. Выберите нужные типы задач.
    3. Щелкните Finish .
    Просмотр представления рабочего процесса Щелкните текст или ссылку на диаграмму рядом с именем рабочего процесса.
    Удаление типа задачи из схемы Щелкните значок x рядом с названием типа задачи, чтобы удалить его.
  5. Опубликуйте черновик, чтобы изменения вступили в силу.

Редактирование, копирование и удаление схем рабочего процесса

  1. Выберите> Проблемы .
  2. В разделе WORKFLOWS щелкните Workflow Schemes .
  3. Проверьте следующие варианты:
Что вы хотите сделать? Шаги
Изменить имя и описание схемы рабочего процесса Щелкните Изменить . Используйте встроенный режим редактирования — щелкните соответствующее поле — чтобы обновить имя и описание.
Копировать схему рабочего процесса Щелкните Копировать , чтобы создать схему рабочего процесса с префиксом «Копия (имя текущего рабочего процесса)» и поместить в неактивные схемы рабочего процесса.
Удалить схему рабочего процесса

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

Связывание схем рабочего процесса с проектом

Ознакомьтесь с разделом «Управление рабочими процессами» для получения дополнительной информации о включении конфигурации рабочего процесса путем связывания схемы с проектом.

Схемы рабочего процесса — Схемы рабочего процесса

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

Команда ITS AASC AAP разработала рабочие процессы, основанные на потребностях пользователей и обратной связи.Эти рабочие процессы должны соответствовать большинству проектов, поскольку в них достаточно шагов для правильного отчета, а также возможность взаимодействия для перехода от открытого к закрытому, если того требует процесс. Эти рабочие процессы предназначены для использования в большинстве проектов. Если есть необходимость разработать индивидуальный рабочий процесс или у вас есть какие-либо вопросы о рабочем процессе, свяжитесь с командой AAP по адресу [email protected]

Orange Tracker предлагает несколько основных схем рабочего процесса:

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

Список улучшений:

  • Кнопка рабочего процесса Комментарий консультанта создает комментарий, который автоматически ограничивается консультантами.
    • Эта кнопка открывает поле для комментариев, доступное только консультантам, и помогает группе создавать комментарии с ограниченным доступом к проблеме.
  • Возможность использования кнопки рабочего процесса Request for Feedback на разных этапах рабочего процесса.
    • Еще одна просьба пользователей заключалась в возможности задать еще один вопрос Репортеру.В настоящее время в стандартном рабочем процессе v2.0, если консультант использует кнопку Request for Feedback и хочет задать другой вопрос, он должен использовать кнопки Start Progress и Stop Progress , чтобы увидеть и использовать кнопку Запрос обратной связи еще раз.
    • Были внесены изменения, которые позволяют кнопке Request for Feedback быть доступной на нескольких этапах рабочего процесса.
  • Статус Resolve был удален, чтобы упростить рабочий процесс и исключить наличие нескольких закрытых статусов.Рабочий процесс по-прежнему имеет существующие кнопки рабочего процесса Resolve Issue и Close Issue , и они будут работать очень аналогично предыдущим кнопкам рабочего процесса.
    • Кнопка Resolve Issue по-прежнему запускает событие Resolve, но переходит в состояние Closed.
    • Кнопка Close Issue запускает событие Close и переходит в состояние Closed.
    • Эти события взаимодействуют со схемой уведомлений, и обычно электронное письмо отправляется репортеру на решение и закрытие зарезервировано как «мягкое закрытие», и электронное письмо не отправляется репортеру.
  • Разрешить и Закрыть Экраны будут содержать одинаковые поля. На обоих экранах есть возможность назначать проблему, связывать проблемы и добавлять компоненты до того, как проблема будет полностью устранена.
    • В предыдущих рабочих процессах экраны «Разрешить» и «Закрыть» имели разные поля, и они должны быть довольно похожи друг на друга. На экране «Решение» были «Разрешение», «Связанные проблемы», «Исполнитель» и «Опрос обратной связи». На экране закрытия было разрешение, исполнитель и компоненты.Проблема в том, что когда пользователи закрывают проблему, они не могут связать другую проблему, или если пользователи решают проблему, они не могут установить компонент.
    • Обзор обратной связи по-прежнему остается только под экраном «Решение», но все остальные поля были добавлены в оба экрана.

Создан в 2015 году. Этот рабочий процесс является наиболее часто используемым рабочим процессом, который мы предлагаем. Этот рабочий процесс является предпочтительным, так как это обновленная версия v1.2.

Этот рабочий процесс основан на версии v1.2 и добавляет еще два перехода:

  • График работы (статус: Запланировано — вы должны установить дату выполнения при планировании работы)
  • Поставить на удержание (статус: На удержании)

Созданные проблемы имеют статус по умолчанию Open. Доступны следующие параметры рабочего процесса: «Начать выполнение», «Запросить отзыв» и в раскрывающемся меню для кнопки «Рабочий процесс»: «Решить проблему», «Закрыть проблему», «Пометить как спам».

Когда проблема находится в статусе «Запланировано», появится кнопка «Перенести».Вы можете использовать это, чтобы изменить срок выполнения проблемы (статус останется «Запланировано»).

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

Апрель 2013 г. Это самый простой рабочий процесс с 6 состояниями:

Созданные задачи имеют статус по умолчанию Открыто.Доступны следующие параметры рабочего процесса: «Начать выполнение», «Запросить отзыв» и в раскрывающемся меню для кнопки «Рабочий процесс»: «Решить проблему», «Закрыть проблему», «Пометить как спам».

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

Если вы закроете проблему, статус будет закрыт, и появится новая кнопка, позволяющая« повторно открыть »проблему (все другие параметры рабочего процесса больше не будут доступны, если вы повторно не откроете проблему).

Кнопка Результирующий статус
Пуск хода Выполняется
Остановить прогресс Открыть
Запросить обратную связь Ожидать обратной связи
Решено
Закрыть Закрыто
Повторно Открыто повторно
Пометить как спам Закрыто (с типом разрешения спама)

Если проблема имеет статус «Ожидание обратной связи» «и Репортер отвечает на электронное письмо, которое было создано в процессе» Запросить отзыв «, статус проблемы будет l автоматически изменится на «Открыть», и электронное письмо от репортера будет добавлено в качестве комментария к этой проблеме.

Назначение схемы рабочего процесса типу контента

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

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

Назначение схем рабочего процесса типу контента

Чтобы назначить одну или несколько схем рабочего процесса типу контента:

  1. Откройте экран Content Model -> Content Types .
  2. Выберите тип контента, которому вы хотите назначить схему рабочего процесса.
  3. На экране редактирования типа содержимого нажмите кнопку РЕДАКТИРОВАТЬ вверху экрана.
  4. Щелкните поле Workflow и выберите, какие схемы рабочего процесса вы хотите присвоить типу контента.

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

Действия рабочего процесса для содержимого с несколькими схемами

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

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

Руководство по передовым методам работы с Jira Workflow [с примерами]

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

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

Примечание. Дополнительные сведения о Jira см. В Руководстве по интуитивно понятному интерфейсу Jira.

Итак, без лишних слов, давайте перейдем к рабочим процессам для Jira:

Что такое Jira Workflows?

Рабочие процессы в Jira моделируют ваши организационные процессы и позволяют выполнять задачи в системе.

В очень простом рабочем процессе это может означать:

  1. Создание проблемы, чтобы отразить новую задачу. У него будет статус «Сделать».
  2. Пометка как «в процессе» после начала работы.
  3. Затем, когда задача будет завершена, вы можете пометить ее как «Выполнено». И вы уже перешли от одного конца рабочего процесса к другому.

В Jira встроены собственные рабочие процессы. К ним относятся:

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

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

Зачем создавать новый рабочий процесс Jira

Создание нового рабочего процесса Jira позволяет адаптировать систему именно к тому, как работает ваша команда.

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

Например, если работа должна быть утверждена, вам может потребоваться добавить дополнительные статусы, чтобы отразить «Ожидает утверждения», «Выполняется проверка» и «Проверка завершена».

Еще одна причина для настройки рабочих процессов — это разнообразие команд. Jira используют самые разные команды — от поддержки клиентов до HR и разработчиков.Раздельные команды также могут получить естественную выгоду от наличия в Jira собственных шаблонов работы и требований.

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

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

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

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

Роль рабочих процессов Jira для команд

Jira позволяет пользователям легко регистрировать задачи и информацию.

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

Таким образом, вы будете отображать, как обрабатываются задачи, устраняя избыточность.

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

Преимущества и недостатки изменения рабочих процессов

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

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

Однако есть недостатки:

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

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

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

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

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

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

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

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

Чтобы команды могли правильно выполнять рабочие процессы в Jira, определенно рекомендуется регулярно проверять этот процесс.

Элементы рабочих процессов Jira

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

Статус рабочего процесса

Проблема может иметь только один статус одновременно. Это может быть что-то вроде «Выполняется» или «Завершено».

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

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

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

Правопреемник Jira

Это то, кому назначена Задача и кто за нее отвечает. И он часто меняется между разными статусами.Когда задача будет завершена, имя исполнителя можно удалить.

Существует несколько подходов к назначению задач в Jira, которые мы обсуждали в нашем посте Передача проблем новому исполнителю Jira (подводные камни и лучшие практики)

Переходы в рабочем процессе

Переход — это одноразовый переход. способ соединения, объединяющий два статуса. Между статусами «Выполняется» и «На рассмотрении» можно перейти на «Отправить на рассмотрение».

Могут быть условия для того, кто может осуществить переход и когда.

Например, только администратору проекта может быть разрешено переместить проблему за пределы статуса «На рассмотрении».

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

В конечном итоге переходы приводят к разрешению.

Устранение проблемы в рабочем процессе Jira

Разрешение — это окончательное состояние проблемы, такое как «Исправлено», «Завершено» или «Не исправить».

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

Как создать новый рабочий процесс Jira

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

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

Чтобы приступить к работе, вам потребуются права администратора Jira.В меню перейдите в «Настройки», выберите «Проблемы», затем «Рабочие процессы», а затем «Добавить рабочий процесс» в правом верхнем углу. Теперь вы готовы назвать свой новый рабочий процесс и приступить к его составлению.

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

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

  • Статус — где проблема (например, «Выполняется» или «На рассмотрении»)
  • Решение — почему проблема больше не находится в стадии разработки (например, потому что она завершена)
  • Условия — контролируют, кто может выполнять переход
  • Валидаторы — разрешают переходы, только если предоставлена ​​конкретная информация
  • Функции поста — вносят дополнительные изменения в задачи наряду с переходами (например, удаление разрешения при повторном открытии проблемы)
  • Триггеры — автоматическая активация переходов при наступлении определенных событий.Например, перемещение проблемы из «Выполняется» в «На рассмотрении» при отправке кода на проверку
  • Свойства рабочего процесса — установка определенных свойств для переходов. Например, отображение только тех разрешений, которые относятся к конкретному типу задачи
  • Схемы рабочего процесса — определение связей между рабочим процессом и типом задачи

Приложения Jira для рабочих процессов

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

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

Вы также можете использовать приложения для создания настраиваемых полей данных.

Для этого вы можете либо создать то, что вам нужно, либо использовать готовое приложение, такое как AM Utils или Insight.

JSU Automation Suite для Jira Workflows

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

JSU Automation Suite для рабочих процессов Jira на Atlassian Marketplace.

AM Utils

AM Utils позволяет автоматизировать создание заявок и другие процессы, используя новые условия, пост-функции и функции JQL.Все это позволяет вам упростить операции, одновременно делая больше и делая это быстрее.

AM Утилиты на Atlassian Marketplace.

Insight for Jira — Asset Management

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

Insight — Управление активами в Atlassian Marketplace

В этой статье также можно узнать больше о Insight for Jira.

Примеры рабочих процессов Jira

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

Это может означать просто перемещение задачи из одного состояния в другое или перемещение задач между несколькими людьми с несколькими состояниями разрешения.

Рабочий процесс поддержки iDalko можно увидеть ниже:

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

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

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

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

  1. Новые возможности создаются и передаются руководителю проекта.
  2. Команда управления портфелем решает, следует ли воспользоваться этой возможностью (и уточнить) или отклонить.
  3. Рассматриваемые возможности подробно описаны с оценкой стоимости разработки и ее ценности.
  4. Опционально возможность может быть задокументирована на слиянии, что позволяет проводить обсуждения в свободной форме и сбор требований.
  5. После того, как вся необходимая информация собрана, возможности переходят в статус «предстоит определить».
  6. На этом этапе может быть принято формальное решение о включении возможности в план развития. Конечно, разработка этой возможности может оказаться дорогостоящей (и быть отвергнута) или отложена, если обстоятельства не благоприятны для начала ее разработки.
  7. Очередь «к доставке» используется отделом НИОКР для выбора возможностей, которые будут включены в будущие выпуски.
  8. Таким образом, ранжирование возможностей очень важно, поскольку НИОКР будут сосредоточены на тех, которые занимают первое место.
  9. R&D переведет возможности в эпосы / истории в релизных проектах.
  10. Статус возможности переходит в «В разработке», и возможность связана с соответствующими эпосами и историями.
  11. После доставки продукта (т.е. доступны для установки на территории заказчика), возможность закрыта.

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

Этот рабочий процесс Jira обеспечивает большую гибкость в том, как можно продвигать проблему.

Рекомендации по тестированию рабочих процессов в Jira

Очень важно протестировать ваш новый рабочий процесс. И он проходит в несколько этапов, начиная с этапа планирования.

Этап разработки нового рабочего процесса

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

Например, как срочные отправления будут перемещаться по системе? Какая информация вам нужна? И как это запечатлено?

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

Этап проверки нового рабочего процесса

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

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

В отличие от тестирования на этапе проектирования, проверка требует, чтобы вы вручную выполняли каждый шаг рабочего процесса.

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

Вы можете собирать и сопоставлять отзывы по ходу дела.

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

Перед запуском вы также захотите предоставить документацию по изменениям.

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

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

Этап производства нового рабочего процесса

День запуска пришел и ушел, и теперь ваш новый рабочий процесс запущен в системе.

Работа закончена? Не совсем.

Что вам еще нужно сделать, так это:

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

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

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

Это может означать:

  • Передача информации от руководителей групп к их командам,
  • Проведение встреч всей компании,
  • Создание элементов блога,
  • Или управление компанией Wiki подробное описание функциональности вашего рабочего процесса Jira.

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

Распространенные ошибки, которых следует избегать при создании рабочих процессов в Jira

Настройка рабочего процесса Jira — сложный процесс. Это значит, что ошибиться легко.

Итак, вот несколько вещей, о которых следует помнить еще на стадии планирования.

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

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

Может возникнуть соблазн создавать на лету, когда вы работаете.

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

Слишком большая настройка рабочих процессов Jira

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

Если так будет продолжаться, то со временем они превратятся в разные виды и не смогут скрещиваться…

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

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

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

Настройка рабочих процессов в Jira без консультации

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

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

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

Заключение

В этом руководстве мы рассмотрели:

  • Что такое рабочие процессы — система для выполнения задач в Jira
  • Почему вы хотели бы создать собственный рабочий процесс — чтобы лучше соответствовать вашим бизнес-процессам
  • различные элементы рабочих процессов — статусы, исполнители, переходы и разрешения
  • Как протестировать рабочий процесс — от проектирования до проверки и развертывания
  • Несколько примеров рабочих процессов Jira
  • И распространенные ошибки, которые люди допускают при создании рабочих процессов, включая проблемы создание повторяющихся статусов, слишком широкая настройка и создание новых рабочих процессов, которые не требуются

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

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

Рекомендуемая литература:

Обзор функций рабочего процесса

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

Видеоурок

Возможности рабочего процесса в админке

Управление схемами

Схемы процессов создаются в интерфейсе административной панели, расположенной в Рабочий процесс / Схемы управления .Когда мы создаем новую схему, DWKit требует присвоить ей имя. Это имя на самом деле является кодом схемы, и это очень важный аспект. Используется для создания процесса по схеме. Т.е. DWKit сообщает Workflow Engine.NET о необходимости создания процесса для определенного документа с определенным кодом схемы (именем). Знание этого имени поможет вам найти процесс в системе, когда вам нужно выполнить с ним нестандартную операцию. Интерфейс создания / редактирования технологической схемы выглядит так, как показано ниже.

Элементы управления в этом интерфейсе выполняют следующие функции:

  1. Переход к интерфейсу со всеми доступными схемами рабочего процесса.
  2. Код открытой схемы (название).
  3. Сохранить — сохраняет схему. Подробнее об обновлении старого процесса до новой схемы (т.е. о версиях схемы) читайте в разделе «Обновление схемы».
  4. Скачать — скачивает XML-файл схемы.
  5. Загрузить — позволяет загрузить XML-файл схемы.
  6. Очистить схему — удаляет все элементы схемы.

Ниже вы найдете элементы управления Workflow Engine.NET Designer со ссылками на соответствующие разделы документации.

  1. Кнопка «Отменить» — отменить предыдущее действие в дизайнере.
  2. Кнопка «Вернуть» — повторяет предыдущее действие в дизайнере.
  3. Создает новое действие.
  4. Создает новое встроенное действие.
  5. Копирует выбранные элементы схемы.
  6. Удаляет выбранные элементы схемы.
  7. Доступ к интерфейсу редактирования, добавления и удаления Актеров. Это связано с созданием правил доступа пользователей к командам схемы.
  8. Доступ к интерфейсу редактирования, добавления и удаления Команд.Т.е. команды, которые отображаются пользователю и которые он может выполнить.
  9. Доступ к интерфейсу редактирования, добавления и удаления таймеров.
  10. Доступ к интерфейсу редактирования, добавления и удаления Код действий . Кодовые действия — это код внутри схемы, который может выполняться как действие или правило (также известное как правило авторизации).
  11. Доступ к интерфейсу редактирования, добавления и удаления параметров процесса.
  12. Доступ к интерфейсу локализации схемы процесса.
  13. Отмечает эту схему как доступную для встраивания.
  14. Обновляет открытую схему схемой, сохраненной в базе данных. Внимание! Эта кнопка сбрасывает все несохраненные изменения!
  15. Автоматическое выравнивание элементов схемы на холсте.
  16. Включает режим отображения расширенной информации об элементах схемы.
  17. Открывает легенду, в которой описаны все условные знаки схемы.
  18. В этом режиме вы можете перемещать холст, щелкая и удерживая левую кнопку мыши.Если этот режим выключен, удерживание левой кнопки мыши приводит к появлению рамки выбора элементов.
  19. Включает отображение дизайнера в полноэкранном режиме.
  20. Устанавливает положение схемы по умолчанию и 100% масштаб.
  21. Увеличить.
  22. Уменьшить.
  23. Текущее значение масштабирования.
  24. Отображает текущее / максимально возможное количество из операций в схеме. Максимально возможное количество определяется лицензионным ключом.
  25. Отображает текущее / максимально возможное количество переходов в схеме.Максимально возможное количество определяется лицензионным ключом.
  26. Отображает текущее / максимально возможное количество Команд в схеме. Максимально возможное количество определяется лицензионным ключом.
  27. Это действие. Он может представлять как промежуточное, так и стационарное состояние процесса. Он также может определять бизнес-состояние процесса или Состояние . Узнайте больше о различиях между Activity и State здесь. Действия, которые необходимо выполнить, задаются с помощью Действия.
  28. Это переход. В центре отображается название Команды, запускающей этот переход. Значок человечка слева от имени команды означает, что этот переход доступен только определенным пользователям.
  29. Это переход. Слева вы видите значок таймера, а название этого таймера находится в центре. При этом переход будет запущен автоматически в соответствии с настройками таймера.
  30. Это условный переход. Вы можете установить условие, которое должно возвращать true для выполнения этого перехода, используя Condition (Action).
  31. Это еще один условный переход. Однако он выполняется, если все остальные условные переходы не могут быть выполнены, потому что их условия вернули false . Другими словами, это последние else в операторе if..then..else .

Управление инстансами

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

Возможна следующая фильтрация. Если задано несколько условий, они соединяются друг с другом с помощью AND.

  1. Идентификатор процесса — идентификатор руководства процесса. Если ваша сущность рабочего процесса (форма) имеет первичный ключ guid, идентификатор процесса будет совпадать с ним.
  2. Схема — код схемы (название).
  3. Статус — статус выполнения процесса. Подробнее о статусах и их значении читайте в разделе «Жизненный цикл обычного процесса».
  4. Имя текущего процесса.
  5. Текущее бизнес-состояние процесса. Узнайте больше о различиях между Activity и State здесь.

Дважды щелкните объект процесса, чтобы открыть конструктор схем в режиме только для чтения. Здесь вы можете изменить состояние процесса и статус .

Этот интерфейс немного отличается от интерфейса редактирования схемы процесса. Давайте посмотрим на различия.

  1. Идентификатор технологического руководства.
  2. Переход к редактированию схемы. Обратите внимание, что это переход к схеме всех процессов, созданных по этой схеме, а не к определенной схеме процесса. Подробнее об обновлении старых процессов на новую схему (т.е. о версиях схемы) читайте в разделе «Обновление схемы».
  3. Установка нового бизнес-состояния для процесса.
  4. Установка нового статуса процесса.
  5. Кнопка, отображающая все параметры определенного процесса.
  6. Текущая деятельность.

Прочие особенности

О других функциях вы можете прочитать в отдельных разделах документации:

Функции рабочего процесса на сервере

Обратите внимание на эти объекты на стороне сервера.

  • Среда выполнения рабочего процесса — это главный объект, который управляет выполнением процесса на сервере. Он настраивается в классе OptimaJet.DWKit.Application / WorkflowInit.cs. Среда выполнения рабочего процесса полностью настроена в DWKit. Однако обратите внимание на следующий код и методы этого класса:
    • runtime.OnWorkflowError + = (sender, args) => {...} — это обработчик ошибок. Возможно, вы захотите это изменить.
    • ActivityChanged (...) — этот метод вызывается, когда процесс переходит от одного действия к другому.
    • .WithActionProvider (ActionProvider ?? new ActionProvider ()) — здесь задается поставщик действий. Он уже включен в проект, но вы можете его изменить.
    • .WithRuleProvider (RuleProvider ?? new RuleProvider ()) — здесь устанавливается поставщик правил. Он уже включен в проект, но вы можете его изменить.
    • .WithTimerManager (TimerManager ?? new TimerManager ()) — здесь устанавливается диспетчер таймера. Таймеры в Workflow Engine.NET без него работать не будет.
  • OptimaJet.DWKit.Application / ActionProvider.cs — Поставщик действий, включенный в проект DWKit.
  • OptimaJet.DWKit.Application / RuleProvider.cs — провайдер правил, включенный в проект DWKit.
  • WorkflowController — клиент взаимодействует с сервером через этот контроллер. Это полностью описано здесь.

Руководство по рабочему процессу JIRA № 7 — Схема рабочего процесса JIRA

20 окт

Учебник JIRA Cloud №4 — Основы и введение в домашнюю страницу Jira

В этом руководстве по облачным вычислениям JIRA мы узнаем об основах и введении в домашнюю страницу Jira.Разберемся в ключевых разделах …

Подробнее

21окт

Учебник JIRA Cloud № 32 — Как создать бэклог Kanban в Jira

В этом руководстве по облачным вычислениям JIRA мы узнаем, как создать бэклог Kanban в Jira. Бэклог — это список …

Подробнее

30 июля

Учебник по администрированию JIRA № 10 — Что такое разрешения для Crowd Directory

В этом руководстве по администрированию JIRA мы узнаем, что такое разрешения для групповых каталогов.Мы узнаем, как …

Подробнее

02 окт

Учебник JIRA № 24 — Как искать тестовые примеры и выполнять массовые изменения

В этом руководстве JIRA мы узнаем, как искать тестовые примеры и выполнять массовые изменения этих тестов …

Подробнее

01 окт

Учебник JIRA №6 — Что такое подзадача в JIRA | Создать подзадачу JIRA

В этом руководстве по JIRA мы узнаем, что такое подзадача в JIRA и как создается подзадача JIRA….

Подробнее

21окт

Учебник JIRA Cloud № 34 — Как искать проблемы в Jira

В этом руководстве по облачным вычислениям JIRA мы узнаем, как искать проблемы в Jira. Есть много вариантов поиска …

Подробнее

30 июля

Руководство по администрированию JIRA №1 — Пользовательские настройки JIRA по умолчанию | Системная панель

В этом руководстве по администрированию JIRA мы узнаем, как обновить системную панель управления JIRA и изменить значение JIRA по умолчанию…

Подробнее

26 окт

Учебник JIRA Cloud № 40 — Как создать панель мониторинга в Jira

В этом руководстве по облачным вычислениям JIRA мы узнаем, как создавать информационные панели в Jira. Вы можете создать новый …

Подробнее

21окт

Учебник JIRA Cloud № 21 — Как включить дорожную карту в Jira

В этом руководстве по облаку JIRA мы узнаем, как включить дорожную карту в Jira.В облаке Jira, если вы …

Подробнее

30 июля

Учебное пособие по администрированию JIRA № 5 — Ведение журнала аудита и устранение неполадок JIRA

В этом руководстве по администрированию JIRA мы узнаем о ведении журнала JIRA и устранении неполадок. Мы узнаем о Jira …

Подробнее

Основы Jira — Модуль 4: Рабочий процесс и статус

Рабочий процесс и статус

Если вы хотите отслеживать рабочие задачи, то самый простой способ классифицировать выполняемые вами работы — это использовать несколько простых значений статуса, таких как «To Do», «In Progres» и «Done».В терминах Jira у вас были бы проблемы с отслеживанием этих частей работы. Затем каждой задаче будет присвоено значение статуса «Задача», «Выполняется» и «Готово».

Если вы еще не приступили к работе, устанавливается статус «Сделать» по проблеме. Когда вы берете работу и начинаете работать над ней, вы перемещаете значение статуса для связанной проблемы на «Выполняется». И, очевидно, как только вы закончите работу, вы переместите значение статуса на «Готово». Это значения статуса, присваиваемые базовому рабочему процессу, настроенному в Jira.Этот рабочий процесс показан ниже:

Что мы имеем в виду, когда начинаем использовать термин «рабочий процесс»? Как мы уже упоминали, мы можем присвоить задачам в Jira значение статуса. Когда мы говорим о рабочем процессе, мы имеем в виду переходы между значениями статуса. Итак, у нас есть переход от «Задачи» к «В процессе». Переход от «В процессе» к «Готово». У нас даже есть переход от «Готово» к «Сделать» (если мы узнаем позже, что нам еще предстоит завершить работу по этой проблеме).

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

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

Решение проблемы в рабочем процессе

Когда вы впервые создадите задачу, ей будет присвоено начальное значение статуса в рабочем процессе.В нашей настройке это статус «To Do», который отображается здесь в новом выпуске:

Когда вы начнете работу над этой проблемой, вы нажмете кнопку «Начать выполнение».

Это нажатие кнопки «Начать выполнение» инициирует переход рабочего процесса от «Задачи» к «Выполняется».

На этом этапе вы увидите, что у вас есть два пути в рабочем процессе.

Из «Выполняется» вы можете вернуться к «Задачи» или перейти к «Готово».Вы можете выбрать, по какому из этих путей следовать, нажав кнопку «Остановить выполнение» или «Готово».

Конечно, если вы нажмете кнопку «Готово», которая вызывает переход из состояния «Выполняется» в состояние «Готово», вы увидите свою проблему с этим установленным значением статуса.

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

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

Выбор начального рабочего процесса

Когда вы создаете новый проект Jira, одно из диалоговых окон, которые вы видите, это опции выбора типа «Создать проект».

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

.

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

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

Просмотр схем рабочего процесса

Если вы хотите изменить рабочий процесс для существующего проекта или создать свой собственный рабочий процесс (со связанными значениями статуса), все начинает усложняться. Функциональность рабочего процесса Jira невероятно гибкая, но с такой гибкостью приходит сложность. Мы рассмотрим полный процесс создания ваших собственных рабочих процессов в одном из будущих модулей. А пока давайте просто посмотрим, как узнать, какие предварительно настроенные рабочие процессы доступны и как изменить рабочий процесс ваших проектов.

Мы можем построить рабочий процесс специально для проекта. Фактически, с точки зрения Jira, мы действительно создаем «схему рабочего процесса» и назначаем эту схему проекту. Схемы рабочего процесса позволяют определять рабочие процессы, а затем применять схему к проекту. Таким образом, схему рабочего процесса можно назначить одному или нескольким проектам. Таким образом, вы можете определить рабочий процесс один раз и легко связать его с проектом (вместо того, чтобы строить рабочий процесс с нуля каждый раз, когда вы создаете новый проект). Эта концепция схем также означает, что вы можете применять согласованность рабочего процесса к проектам.И когда вы вносите изменения в схему рабочего процесса, это изменение автоматически применяется ко всем соответствующим проектам.

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

На странице администратора «Проблемы» вы найдете список меню слева. Здесь вам нужно выбрать «Схемы рабочего процесса».

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

Теперь мы рассмотрим все схемы рабочего процесса. Доступные, но не назначенные ни одному из проектов (Неактивные). А те, которые есть в наличии и были закреплены за проектом (активным)

Щелкните ссылку под заголовком «Рабочий процесс» для строки.

После этого вы перейдете на страницу, где определены рабочий процесс и значения статуса.Вы можете просматривать рабочий процесс как в форме «Текст» (то, что вы видите сейчас), так и в форме «Диаграмма». Нажмите кнопку «Диаграмма», чтобы увидеть диаграмму рабочего процесса

.

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

Намного легче усвоить Я думаю, вы согласитесь. Вы также заметите, что этот рабочий процесс («классический» рабочий процесс) немного сложнее, чем наш простой рабочий процесс «ToDo -> In Progress -> Done», который мы уже видели.

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

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

Изменение схемы рабочего процесса, применяемой к проекту

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

Отсюда, в левом нижнем углу, вы найдете ссылку «Настройки проектов».

Когда вы перейдете на страницу настроек проекта, вы увидите вариант рабочих процессов в списке настроек:

После того, как вы выберете, вы увидите опцию «Переключить схему».

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

Отсюда мы захотим перейти к нашей «Классической» схеме. В раскрывающемся списке выберите «Classic» и нажмите кнопку «Assoiciate».

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

Текущее Новое

ДОЛЖНЫ ДЕЙСТВОВАТЬ Открыть
В ПРОЦЕССЕ Выполняется
Решено
Повторно открыто
ВЫПОЛНЕНО Закрыто

Несколько важных моментов:

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

2. В представленном списке, даже если у вас может быть текущее значение статуса, скажем «Выполняется», если у вас НЕТ проблем с этим статусом, вам не нужно определять сопоставление.

В нашем примере Jira начинает предлагать следующее сопоставление для наших типов задач «Задачи»:

Обратите внимание, что Jira сообщает нам, что у нас есть 10 проблем типа «Задача», на которые влияет это сопоставление. Это говорит нам о том, что эти 10 задач находятся в состоянии «ДЕЛАТЬ» или «ВЫПОЛНЕНО».Таким образом, это как раз те состояния (для этих 10 проблем), которые нам нужно проинструктировать Jira о сопоставлении. Итак, мы выберем правильное сопоставление и нажмем «Связать».

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

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

Использование классической схемы рабочего процесса

Чтобы увидеть, что происходит с этим новым рабочим процессом, нажмите кнопку «Создать» вверху страницы:

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

На странице создания введите данные в обязательные поля (Сводка и Отчет).

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

И если вы нажмете ссылку «Просмотреть рабочий процесс», вы увидите графическое представление рабочего процесса, за которым последует эта проблема:

И если вы закроете это диалоговое окно, вы сможете поэтапно выполнить свою проблему через различные этапы рабочего процесса с помощью кнопок «Назначить», «Решить проблему» и «Закрыть проблему».

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

Сводка

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *