Модель процесса и его описание см. приложение.
С уважением,
Стороженко А.Д.
Файлы
-
Описание_процесса.doc (28.5 KB, 40 downloads) 11 лет old -
Планировать_произво (42.5 KB, 44 downloads) 11 лет old
-
Опубликовано 11 лет назад #
-
Произвёл замену модели, т.к. она не читалась
Файлы
- Ot_idei_do_prodykta.bpm (42.5 KB, 45 downloads) 11 лет old
Опубликовано 11 лет назад # -
-
Теперь читается.
Опубликовано 11 лет назад # -
Александр, предлагаю для лучшего понимания логики процесса свернуть схему до 3-х прямоугольников.
Судя по схеме мы говорим о полноценных процессах.
Вопросы:
1. Чем отличаются 2 сообщения с одинаковым наименованием ТД?
2. Какие основные функции у Рук ПДБ и Рук ПДГ?Опубликовано 11 лет назад # -
1. Нельзя ли на дорожке «Рук ПДГ цеха» соединить задачи «Регистрировать СЗ», «Заказать ТД», «Получить ТД» и «Регистрировать ТД и СЗ» на одной магистрали и вместо двух стартов сделать один?
2. Если время выполнения заданий на дорожке «Участки цехов» в какой-то момент стало очень большим, тогда последовательно идущие задачи «Прогнозировать…» и «Анализировать…» тоже отодвинутся во времени? Может быть лучше их сделать параллельными процессами?
3. Что будет, если за месяц или за два ни один договор производства не будет заключен? Опять же процессы "Анализировать" и "Прогнозировать" будут не задействованы.Опубликовано 11 лет назад # -
Цитирую: Александр Васильев
Александр, предлагаю для лучшего понимания логики процесса свернуть схему до 3-х прямоугольников.
. Ответ: Не представляю, как это сделать без потери смысла модели1. Чем отличаются 2 сообщения с одинаковым наименованием ТД?
Ответ: Это не сообщение, а аннотации (комментарии), поясняющие что по соответствующей связи поступает ТД.
2. Какие основные функции у Рук ПДБ и Рук ПДГ?
Ответ: Основная функция рук. ПДБ - составление плана работ для цехов, для рук. ПДБ - составление сменно-суточных заданий для участков цеха.Опубликовано 11 лет назад # -
Цитирую Максим Плотников
1. Нельзя ли на дорожке «Рук ПДГ цеха» соединить задачи «Регистрировать СЗ», «Заказать ТД», «Получить ТД» и «Регистрировать ТД и СЗ» на одной магистрали и вместо двух стартов сделать один?
2. Если время выполнения заданий на дорожке «Участки цехов» в какой-то момент стало очень большим, тогда последовательно идущие задачи «Прогнозировать…» и «Анализировать…» тоже отодвинутся во времени? Может быть лучше их сделать параллельными процессами?
Ответ: Согласен. Учту в модели.3. Что будет, если за месяц или за два ни один договор производства не будет заключен? Опять же процессы "Анализировать" и "Прогнозировать" будут не задействованы.
Ответ:
1. Такой ход событий, по моему, нереален. Но ежели события пойдут в этом направлении, директор его прервёт задолго до истечения даже первого месяца.
2. Ну а ежели наша непредсказуемая жизнь пойдёт-таки в это русло, то Вы правы, упомянутые задания задействованы не будут, ибо потеряют смысл.Опубликовано 11 лет назад # -
Давайте попробуем убрать все сообщения. Линий станет меньше, и теперь можно будет увидеть лишние переходы и лишние элементы на диаграмме (номера с 1 по 4). А еще увидим незавершенность одной из веток процесса (номер 5)
Уберем лишние линии. Без них диаграмма читается легче:
А если вспомнить, что мы рисуем не должностные инструкции, а процесс, можно еще упростить диаграмму, отказавшись от дорожек исполнителей:
Вот. Теперь с диаграммой можно работать.
Файлы
-
Image_3.png (121.5 KB, 33 downloads) 11 лет old - Image_2.png (72.5 KB, 12 downloads) 11 лет old
- Image_0.png (79.6 KB, 8 downloads) 11 лет old
Опубликовано 11 лет назад # -
-
Цитирую (повторно) Максим Плотников
2. Если время выполнения заданий на дорожке «Участки цехов» в какой-то момент стало очень большим, тогда последовательно идущие задачи «Прогнозировать…» и «Анализировать…» тоже отодвинутся во времени? Может быть лучше их сделать параллельными процессами?
Ответ (повторно, после дополнительных размышлений): И всё-таки реализовывать это предложение нельзя, т. предмет задач "Прогнозировать..." и "Анализировать..." появляется после "Выполнения заданий...". Поэтому в этой части модели оставлю ей первоначальное состояние.Опубликовано 11 лет назад # -
А еще я бы подумал над разделением процесса на отдельные "Прогнозировать", "Анализировать" и "Выполнять задания" и т.д. Сейчас у вас полный цикл производства "в одном флаконе". Несколько процессов и читаться легче будут, и рисоваться, да и вообще... :)
Опубликовано 11 лет назад # -
Цитирую Pavel-Smirnov
"Давайте попробуем убрать все сообщения. Линий станет меньше..."
Ответ: Согласен, что отвлекают. Но при этом теряется способность модели определять, какому из участников для выполнения какго задания нужна какая информация (ну, хотя бы, из какого хранилища). Ведь одной из задач модели является "путеводительствование" нами при грядущей интеграции разрозненных и принадлежащих разным подпроцессам автоматизированных систем. Но, видимо, решение этой задачи - суть последующего этапа.
Убираю."и теперь можно будет увидеть лишние переходы и лишние элементы на диаграмме (номера с 1 по 4)"
Ответ: Этими расхождениями и схождениями я хотел показать (может и неудачно), что по зашедшей на производство любым из двух указанных способов ТД рано или поздно (что определяется планированием) будут в цехах осуществляться соответствующие производственные работы.
. Жду Вашего мнения, а обсуждаемый узел пока не меняю." А еще увидим незавершенность одной из веток процесса (номер 5)
Ответ: Реализацией первого замечания Максима Плотникова это замечание устраняется."А если вспомнить, что мы рисуем не должностные инструкции, а процесс, можно еще упростить диаграмму, отказавшись от дорожек исполнителей:
Ответ: Эта часть Вашего текста и соответствующее прикрепление не визуализировалась. Прошу повторить.Опубликовано 11 лет назад # -
Цитирую ADSmb:
"А если вспомнить, что мы рисуем не должностные инструкции, а процесс, можно еще упростить диаграмму, отказавшись от дорожек исполнителей:
Ответ: Эта часть Вашего текста и соответствующее прикрепление не визуализировалась. Прошу повторить.Как так "не визуализировалась"? Даже в вашем сообщении я вижу свою картинку. наверное, я просто нехорошо объяснил. Попробую еще раз:
Кода вы проектируете процесс, в первую очередь сосредоточтесь на логике (переходов, действий). Проследите и продумайте все шаги. Когда станет ясно "что надо делать", назначьте исполнителей (кто будет делать). Добавьте на диаграмму дорожки и разнесите элементы по дорожкам. Если проектировать диаграмму сразу с учетом исполнителей - это сложно (обилие линий будет мешать увидеть картинку в целом).
А еще лучше - вообще не пользоваться дорожками, потому что без них любая схема будет читаться лучше (ну а исполнителей можно и в комментариях к процессу подписать)Опубликовано 11 лет назад # -
Цитирую ADSmb:
Цитирую Pavel-Smirnov
"и теперь можно будет увидеть лишние переходы и лишние элементы на диаграмме (номера с 1 по 4)"
Ответ: Этими расхождениями и схождениями я хотел показать (может и неудачно), что по зашедшей на производство любым из двух указанных способов ТД рано или поздно (что определяется планированием) будут в цехах осуществляться соответствующие производственные работы.
. Жду Вашего мнения, а обсуждаемый узел пока не меняю.Ничего не понял из вашего объяснения :) Но "по-любому" на диаграмме не должно быть никаких лишних элементов. Все, что вы хотели бы дополнительно рассказать, надо рассказывать не через создание ненужных элементов, а простым описанием (комментарием к диаграмме)
Опубликовано 11 лет назад # -
Хм... Третья и недошедшая сразу до меня схема Павла Смирнова "приаттачилась" к моему ответу. Но теперь я понял смысл его последнего предложения.
...........................................................................................................................
Ответ: Я читал, что дорожки - опциональны, т.е., как понимаю, не обязательны. Но как тогда можно исполнить процесс (просто его нарисовать мне недостаточно, для этого я 10 лет использую IDEF0), не имея принципиально важной (на мой взгляд) для этого информации об исполнителях??? Хотя я помню слова Анатолия Анатольевича, что кто исполняет - это вторично. То есть я ещё более заинтригован реальным содержанием термина "исполнять процесс".
Прикрепляю версию модели в состоянии с учётом предыдущего своего ответа.Файлы
- Ot_idei_do_prodykta_(vo_DS).bpm (39.3 KB, 14 downloads) 11 лет old
Опубликовано 11 лет назад # -
-
Цитирую Pavel-Smirnov
Кода вы проектируете процесс, в первую очередь сосредоточтесь на логике (переходов, действий). Проследите и продумайте все шаги. Когда станет ясно "что надо делать", назначьте исполнителей (кто будет делать). Добавьте на диаграмму дорожки и разнесите элементы по дорожкам. Если проектировать диаграмму сразу с учетом исполнителей - это сложно (обилие линий будет мешать увидеть картинку в целом).
А еще лучше - вообще не пользоваться дорожками, потому что без них любая схема будет читаться лучше (ну а исполнителей можно и в комментариях к процессу подписать.
Ответ: Ваша схема мною безусловно понимаема. И принимаема, но с оговоркой: как можно "сосредотачиваться на логике переходов, действий" без учёта их исполнителей? Ведь некоторые из заданий на схеме (три крайних справа на Вашей версии) меняют своё содержание в зависимости от исполнителя. Держать всё это в голове до момента перехода ко второй фазе (собственно назначению исполнителей)?
Наверняка, мне предстоит ломка некоторых нажитых "непосильным трудом" стереотипов :-). В том числе тех, которые определяют степень нужности ("лишнести") элементов на схеме.Опубликовано 11 лет назад # -
Исполнители в исполняемой диаграмме (извините за тавтологию) непременно должны быть назначены, но кто сказал, что это должно делаться визуально через дорожки?
И если уж на то пошло, дорожки не задают исполнителя строго, а намекают на него. С точки зрения исполнения их вес такой же, как у комментариев - настоящий исполнитель задается в атрибутах задачи и на графической схеме не отображается.
Опубликовано 11 лет назад # -
Александр,
На счет проблемных изделий. Я понимаю , что это изделия, которые не успели выполнить в срок по плану.
Что если добавить в схему таймеры и условные развилки, например "Есть проблемные изделия?" и соответственно закрывать договора только "готовых изделий", после чего передавать готовые изделия заказчику.
А "Прогнозировать" и "Анализировать" сделать только для "проблемных изделий"?
Опубликовано 11 лет назад # -
Цитирую Анатолий Белайчук
Исполнители в исполняемой диаграмме (извините за тавтологию) непременно должны быть назначены, но кто сказал, что это должно делаться визуально через дорожки?И если уж на то пошло, дорожки не задают исполнителя строго, а намекают на него. С точки зрения исполнения их вес такой же, как у комментариев - настоящий исполнитель задается в атрибутах задачи и на графической схеме не отображается.
Ответ: Воспринял. Но, на мой взгляд, это неотображение снижает эффективность совместной работы ИТ и бизнеса, которому явно будет не хватать явного вида столь существенной для него информации. Ну не будет же он лазить по каждой задаче в её аттрибуты!
Хотя, сознаю, что забегаю вперёд. Жду 30.06 и, с особенным нетерпением, 7.7.Опубликовано 11 лет назад # -
Поясню свою позицию: меня учили, что первый вопрос, на который должен сам себе ответить бизнес - "КТО?". Кто будет решать ту или иную задачу? Смысл такой философии: отсутствие ответа на этот вопрос зачастую лишает смысла ответ на вопрос "Что (надо делать)?"
Опубликовано 11 лет назад # -
во вложении вариант с развилкой по проблемным изделиям
Файлы
- problemnie_isd.bpm (44.1 KB, 10 downloads) 11 лет old
Опубликовано 11 лет назад # -
-
то же самое, только с разделением на 2 процесса
Файлы
- problemnie_isd_2.bpm (42 KB, 15 downloads) 11 лет old
Опубликовано 11 лет назад # -
-
Цитирую ADSmb:
Поясню свою позицию: меня учили, что первый вопрос, на который должен сам себе ответить бизнес - "КТО?". Кто будет решать ту или иную задачу? Смысл такой философии: отсутствие ответа на этот вопрос зачастую лишает смысла ответ на вопрос "Что (надо делать)?"Не могу согласиться. Сначала ЧТО надо сделать, потом КОМУ это поручить. В этой философии мы нацелены на конечный результат - как лучше всего выполнить свою работу и максимально удовлетворить клиента. Все деятельности, не являющиеся необходимыми для достижения цели, являются лишними и должны быть ликвидированы - перевод с японского :)
Опубликовано 11 лет назад # -
Цитирую Максим Плотников,
"На счет проблемных изделий. Я понимаю , что это изделия, которые не успели выполнить в срок по плану.
Что если добавить в схему таймеры и условные развилки, например "Есть проблемные изделия?" и соответственно закрывать договора только "готовых изделий", после чего передавать готовые изделия заказчику".
Ответ: Предложения справедливы:
1. Особенно по причине моего медленного "въезжания" в палитру изобразительных возможностей BPMN и BizAgi (а в нём, оказывается ещё есть какая-то Java-совместимая среда разработки!!!).
2. И учитывая не отображение мною реально сущестующей веточки частичного закрытия договоров на величину фактически выполненных работ.
Подумаю, как это отобразить."А "Прогнозировать" и "Анализировать" сделать только для "проблемных изделий"?"
Ответ: Спасибо, подумаю.Опубликовано 11 лет назад # -
Вы нарисовали причинно-следственную связь, но не процесс. Не могут 13 действий выполняться строго последовательно. Не бывает так в жизни. Вот по любому это несколько процессов, взаимодействующих между собой.
И зачем вам таймер на 25-ое число? Если вы зарегистрируете договор после 25-го числа, ваш процесс застрянет на ожидании 25-го числа следующего месяца.
Файлы
- Image_13.png (13.4 KB, 3 downloads) 11 лет old
Опубликовано 11 лет назад # -
-
вопрос "на засыпку": а что делает производство до того момента, как рассортируют ТД по участкам цеха? Шаг "Выполнять задания" следует строго за этим шагом. А до этого момента рубильник не включать?
Опубликовано 11 лет назад # -
Цитирую Pavel-Smirnov
1. "Вы нарисовали причинно-следственную связь, но не процесс. Не могут 13 действий выполняться строго последовательно. Не бывает так в жизни. Вот по любому это несколько процессов, взаимодействующих между собой".
Ответ: Вполне допускаю. Зато будет ещё одна тема на завтрашнюю встречу :-). Ккстати, чтобы уйти от специфичного числа 13 добавил в модель дополнительные задания (см. ниже) :-))
Заодно ещё немного увеличил реалистичность модели:
1.1 Уточнил, что на основной старт ТД приходит в сопровождении Листка Запуска изделия (в противовес приходящим на второй вход Служебным Записка на запуск).
1.2. Попытался отразить, что составление сменно-суточных заданий производится по вложенному циклу: первый - по строкам Спецификации изготавливаемого изделия, второй (вложенный) - по строкам Маршрутной Карты, описывающей перечень производимых на участках операций над ДСЕ (деталями и сборочными единицами), из которых изготавливаемое изделие состоит
1.3 Добавил задания, связанные с нередким частичным закрытием договора, особенно когда изготовление затягивается на много месяцев.2. "И зачем вам таймер на 25-ое число? Если вы зарегистрируете договор после 25-го числа, ваш процесс застрянет на ожидании 25-го числа следующего месяца".
Ответ: А затем, чтобы Вы указали на очередную моё ошибку :-). Я же познаю не только BPMN, но и само производство, в котором всего полтора года, и которое вместе со своими старожилами не спешит раскрывать передо мною все свои узкие места и способы их рсширения.
Поэтому мои модели и носят подчас наивный характер.Ну а сейчас выкладываю последнюю версию, которую и будем обсуждать завтра.
Файлы
- Ot_idei_do_prodykta.bpm (38.5 KB, 17 downloads) 11 лет old
Опубликовано 11 лет назад # -
-
Цитирую Юлия Вагнер
вопрос "на засыпку": а что делает производство до того момента, как рассортируют ТД по участкам цеха? Шаг "Выполнять задания" следует строго за этим шагом. А до этого момента рубильник не включать?
Ответ: Видимо и впрямь включать рубильник смысла не имеет. ведь именно в ТД записаны, например, режимы резания станка, включаемым эти рубильником. Но повторюсь (см предыдущий ответ) я ещё плохо понимаю философию BPMN и не удивлюсь, ежели Вы докажете, например, что эти два задания надо поменять местами.Опубликовано 11 лет назад # -
Цитирую: Юлия Вагнер
вопрос "на засыпку": а что делает производство до того момента, как рассортируют ТД по участкам цеха? Шаг "Выполнять задания" следует строго за этим шагом. А до этого момента рубильник не включать?
Ответ: Прошу прощения, но я ответил только на второй Ваш вопрос.
Из всего того, что оно делает в интересующий Вас момент, главное, с точки зрения модели, - изготавливает ранее запущенные изделия, в частности, входящие в них детали и сборочные единицы.Т.е. рубильник, в общем виде, включен в предыдущем экземпляре процесса, который как понимаю, в моём случае соответствует запущенному в производство изделию.Опубликовано 11 лет назад # -
Я вижу, название процесса в итоге абсолютно не соответствует содержимому.
Поправьте меня если я не прав, но вроде изначально речь шла о процессе *разработки* продукции. Т.е. от идеи "а давайте разработаем вот такую железяку", через последовательность эскизных и рабочих проектов, с согласованием и выделением бюджета (а бывает, что и несогласованием и невыделением) - до счастливого момента, когда все чертежи изготовлены и утверждены, оснастка изготовлена, снабженцы знают какие комплектующие и где брать, а производство готово новую продукцию выпускать.
По факту же у нас совершенно другой процесс, в котором фигурируют договора и планы производства.
Мда... придется разбираться на месте.
IDEF0 - зло ;)
Опубликовано 11 лет назад # -
По итогам субботнего тренинга, проект, как представляется. приобрёл свой искомый "процессный" вид. Название процесса "Разрабатывать квартальный план производства". Модель прилагается.
P.S. И дело, скорее всего, не в IDEF0, а в умении соблюдать границы его применения.
Файлы
- Q_planning.bpm (30.1 KB, 30 downloads) 11 лет old
Опубликовано 11 лет назад # -
-
Зачет.
Опубликовано 11 лет назад # -
О, ну так это уже процесс! :)
Опубликовано 11 лет назад # -
А как еще можно улучшить данный процесс?
Опубликовано 3 года назад #
Ответ
Вы должны авторизоваться, чтобы публиковать сообщения.