Нотация IDEF0 и еще раз про построение структуры бизнес-процессов компании. (Часть 2)

Нотация IDEF0 и еще раз про построение структуры бизнес-процессов компании. (часть 1)
October 1, 2014
Бизнес-процессы и системный подход.
October 3, 2014
Показать все

Нотация IDEF0 и еще раз про построение структуры бизнес-процессов компании. (Часть 2)

Нотация IDEF0 и еще раз про построение структуры бизнес-процессов компании. (Часть 2)

Сделаем дальнейшую декомпозицию, например, работы «Комплектовать товар» (смотрите рисунок 4).  Я детально проанализирую данную диаграмму, чтобы проиллюстрировать и использование нотации, и соблюдение логики процессов и принципов процессного подхода, и построение структуры процессов компании, и выполнения анализа регламентов бизнес-процессов.  Все работы на этой диаграмме для своего выполнения используют персонал склада, складскую технику, складской комплекс (как специально оборудованное здание со стеллажами, проездами, рампами, воротами и т.д.) и, конечно же, специальное программное обеспечение. Я умышленно не стал проводить соответствующие стрелки, чтобы не усложнять восприятие диаграммы. На диаграмме размещено 6 работ, которые мы последовательно рассмотрим.

i4

Рисунок 4. Диаграмма декомпозиции работы «Собирать и отгружать товар».

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

«Комплектовать заявки». На вход данной работы поступают задания на сбор, в соответствии с которыми и происходит сбор  товара. После сбора товара, его передают в следующую работу для проверки комплектаций. Еще одним выходом будет информация о том, что при сборе какого-то товара не было обнаружено (или вообще, или на указанном в задании месте). Обратите внимание, данная информация передается не непосредственно в работу по снятию остатков, а в управляющую работу по планированию деятельности склада, и уже оттуда будет идти команда на снятие остатков. При этом работа по проверке самих комплектаций запуске сразу из работы по сбору, инициирующим событием при этом является сам факт появления собранной комплектации в зоне проверки, где работа происходит по принципу FIFO.  Я привел такой вариант просто как пример возможного порядка управления работами на складе (хотя его можно экстраполировать и на другой вид деятельности). Такой вариант будет предпочтительным для ситуации, когда с одной стороны есть ограниченные ресурсы персонала, ведь чтобы снять остатки товара нужно привлекать не только работников специальной группы качеств, но и складскую технику с водителями, а также, возможно, и останавливать работы по сбору. С другой стороны, такой вариант предпочтительней, когда основная цель произвести отгрузки вовремя, пусть даже и ценой ошибок в комплектациях Такая ситуация возможна, когда склад обслуживает продуктовые сети, и можно пожертвовать недостачей нескольких единиц одного товара ради того, чтобы доставка была выполнена вовремя. Если же склад обслуживает какое-либо производство, то такой вариант управления работами, скорее всего, будет неподходящим, ведь ошибка в комплектации может привести к остановке производства.

«Проверять остатки». Запускается данная работа по распоряжению на снятие остатков, а результатом ее является отчет об остатках товара, который в нашем примере уходит в «никуда» и вообще обозначен странной стрелкой с квадратными скобками. Об этих скобках мы поговорим чуть позже. А куда она могла бы идти, исходя из ранее описанной логики управления работа в нашем случае?  На нашей схеме мы можем инициировать снятие остатков товара в двух случаях, если товар не нашли при комплектации, и если по прибытию в точку разгрузки в комплектации все-таки оказалась недостача, тогда надо проверить не забыли ли, например, товар на складе при погрузке в машину. В общем, мы сняли остатки,  что дальше делать? Во-первых, надо сообщить клиенту (внутреннему или внешнему), чтобы он мог отразить это в учете и сообщить, что делать дальше, например, включить его, если его нашли,  в следующую заявку на доставку в эту дочку разгрузки товара. Во-вторых, хорошо бы отправить этот отчет в какой-нибудь процесс по учету и хранению товара для приведения учета в соответствии с фактом. И тут всплывает интересный момент, связанный с нашей усеченной структурой бизнес-процессов (напомню, что мы взяли для описания только одну часть цепочки создания ценности). А такого процесса у нас на схеме нет, то есть мы просто отправим его за пределы нашей системы. Кроме того снятие остатков может также происходить и при инвентаризации (плановой  или по просьбе поклажедателя). А в случае недостачи в точке разгрузки может потребоваться связаться с другими точками разгрузками по пути следования автомобиля, может им выгрузили лишний товар. Но, так как наша схема несколько урезанная, то нам просто неоткуда вызвать соответствующие события. Ну и напоследок обратите внимание на то, что у нас опять нарушена нотация – задание на снятие остатков поступает на вход работы слева, а не как управляющая стрелка сверху. Кроме того не понятно, а с чем-то собственно проводятся операции в данной работе, так как на вход не поступают никакие материальные объекты.

«Проверять комплектации». Работа, связанная с проверкой комплектаций после сбора. Как мы уже говорили, на вход подается собранный товар, что и является инициирующим событием. Для того, чтобы проверить комплектацию необходимо знать, что в ней должно быть. В нашем случае никакой соответствующей информации не передается. Тут может быть два варианта (вариант того, что ошиблись и забыли,  упустим). Первый вариант – вся необходимая информация находится в ПО (WMS – система управления складом), второй вариант – все соответствующие документы на товар, независимо от его состояния (собранный, проверенный, отгруженный, доставленный), находятся вместе с ним, но это необходимо прописать при стандартизации входов-выходов.  Я все равно бы не смог полноценно отобразить на нашей «урезанной» диаграмме появление накладных документов, т.к. как это довольно большой и «емкий» процесс.

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

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

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

«Отчитываться о работе склада». На вход данной работы поступают различные отчеты, там они как-то обрабатываются (для нас это пока «черный ящик», как собственно и все остальные работы) и на выходе получается «Отчет о работе склада». Который идет… он опять идет в «никуда». Как так получилось?

Отвлечемся немного от отчетности и вернемся к нотации IDEF0, а точнее к туннелированию стрелок. Когда мы рисуем диаграммы работ нижнего уровня, мы часто по ходу описания добавляем граничные стрелки, которых не было на верхних уровнях. Их там не было  потому, что мы или посчитали их не существенными для верхнего уровня, или просто забыли. Когда мы добавляем такие стрелки, они помечаются квадратными скобками возле границы диаграммы, как стрелка «Отчет об остатках товара» на рисунке 4. Конечно, это происходит, если мы рисуем диаграмму в специальной программе типа ERWin, если мы рисуем диаграмму в программе вроде MS Visio, то она стрелки никак не помечаются. Но суть в другом, суть в том, что нам дальше с этими стрелками делать. Первый вариант это затоннелировать стрелку, то есть сделать так, чтобы она не попала на другую диаграмму. Это соответствует тому, что стрелка выходит за пределы описываемой системы, но как несущественный выход или вход. Как раз такая ситуация у нас со стрелкой «Письмо о приеме/отклонении заявки». Это письмо, которое мы отправляем клиенту, для того, чтобы сообщить ему о том, что его заявка принята или отклонена по каким-либо причинам. И эта стрелка не отображена на диаграмме более высокого уровня (смотрите рисунок 3). Второй вариант это мигрировать стрелку на диаграмму верхнего уровня. Именно так мы поступили со стрелкой «Товар на складе». Посмотрите на рисунок 1 – там этой стрелки нет, когда я начал выстраивать декомпозицию контекстной диаграммы я добавил эту стрелку, а затем мигрировал ее на верхний уровень (смотрите рисунок 3). Тоже самое произошло со стрелкой «Отчет о работе склада», на диаграмме верхнего уровня ее нет (смотрите рисунок 2, у работы «Комплектовать товар» такого выхода нет), а вот на рисунке 4 он появляется, затем я мигрировал его на верхний уровень, и эта стрелка появилась и на диаграмме верхнего уровня (смотрите рисунок 5). Я «отправил» эту стрелку как обратную связь (про типы внутренних стрелок поговорим немного ниже) в работу «Принимать и обрабатывать доставки», то есть она не выходит за пределы этой диаграммы и ее не надо ни мигрировать, ни тоннелировать.

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

i5

Рисунок 5. Изменённая диаграмма декомпозиции работы «Выполнять заявки клиентов по доставке товаров».

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

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

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

  • Связь по входу (input-output) , когда стрелка выхода одной работы идет на вход другой работы. То есть предыдущая работа «производит» сырье или полуфабрикаты для другой работы.

На этой диаграмме на рисунке 4 к связям по входу-выходу относятся, например, стрелка «Собранный товар» и стрелка «Собранный и проверенный товар».

На диаграмме на рисунке 5 – стрелка «Собранный, проверенный и отгруженный товар» (тоже не лучшее название выхода: оно детально отражает его суть, но при этом излишне и занимает место на схеме, очевидно, что несобранный и не проверенный товар не может быть отгружен) и «Отчет о доставке»

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

На диаграмме на рисунке 5 примером такой связи может быть «Распоряжение снять остатки». Могли бы еще быть «План комплектации» и «План доставки», если бы были не была нарушена нотация.

  • Обратная связь по входу (output-input feedback, когда выход нижестоящей работы направляется на вход вышестоящей. Это может информация, как «Отчет о работе склада». Или материальные потоки, например брак может отправляться в начало цикла производства на переделку.
  • Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей. На рисунке 5 такому варианту соответствует стрелка «Распоряжение снять остатки товара».
  • Связь выход-механизм (output-mechanism), когда выход одной работы направляется на ресурсный (нижний) вход другой работы. Стрелка довольно редкая. Чаще используется, чтобы показать, что одна работа подготавливает ресурсы необходимые для другой.

Скорее всего, вы уже обратили внимание, что на некоторые стрелки на рисунках разветвляются или сливаются. Такое происходит, когда результат одной работы используется в нескольких других работах, либо различные работы производят одинаковый продукт, который затем используется в одной работе. Еще одна ситуация, когда стрелки разделяются, когда какой-либо ресурс или управляющий документ используется в нескольких работах. При этом, если это именно один и тот же документ или ресурс, то стрелка будет иметь одно наименование, находящееся перед разветвление. Например, ресурсная стрелка ПО (программное обеспечение) на рисунке 5. Если же первоначальный ресурс или документ являлся общим массивом для ресурсов или документов после разветвления, то каждая стрелка после разветвления имеет собственное наименование. На рисунке 5 таким образом разветвляется стрелки «Персонал» (на стрелки «ОЛ» – отдел логистики, «Работники склада» и «Работники СД» — служба доставки) и «Регламенты» (на стрелки «Регламент планирования», «Регламент отчетности», «Регламент работы склада» и «Регламент работы СД»). Если часть стрелок после разветвления поименованы, а какая-либо – нет, то считается, что она соответствует стрелке до разветвления. Считается ошибкой, когда стрелка до разветвления не именована, а после разветвления не именованная какая-либо ветвь. Правила наименования для сливающихся стрелок аналогичны. Ошибкой будет, если после слияния стрелка не поименована, а до слияния при этом не поименованная какая-либо из ветвей.

И еще собственно про нотацию IDEF0. Нумерация работ. Тут все довольно просто, смотрите рисунок 6.

i6

Рисунок 6. Пример нумерации работ в нотации IDEF0.

Номер состоит из префикса и числа. Сам префикс моет быть любой длины, но чаще используют префикс А. Контекстная диаграмма имеет номер 0 после префикса, работы на первой декомпозиции – 1, 2, 3 и т.д. У работ на последующих декомпозициях первая цифра (или цифры) в числе наследуется от родительской работы, а последняя цифра ее номер на декомпозиции.

Продолжение следует.

© Сагалович Александр

Минск. Октябрь 2014.

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