DRAKON.SU

Целое предприятие (аквапарк Лазурный) решило использовать ДРАКОН - это большой прорыв для языка, настоящий праздник.

Надеюсь, что оценка эффективности не приукрашена работниками. Буду рад увидеть дальнейшие внедрения ДРАКОНа в профессии.
__________________________________

Прочитал книгу, прикреплённую к сообщению в теме:
viewtopic.php?f=242&t=7167.

Для меня было интересно почитать именно представление бизнес-процессов в языке ДРАКОН, потому что я ленивым прогулочным шагом пишу доклад, в котором сравниваю дракон-схемы с UML, BPMN и блок-схемами (вдруг пригодится).

Эти более близкие аналоги Владимир Паронджанов порекомендовал мне исследовать вместо R-диаграмм Игоря Вельбицкого и диаграмм Насси-Шнайдермана.

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

Поэтому я её как следует прочитал и записал возникшие комментарии, вопросы, замечания.

1. Удивился факту существования школы по ДРАКОНу. Ранее на просторах форума не видел её упоминания. Но, порывшись немного, всё-таки нашёл информацию.
Если кто-то захочет быть в курсе дела, на форуме есть соответствующая тема:
viewtopic.php?f=139&t=5369.

2. Не понял в содержании выделения "Алгоритмов взаимодействия" из "Алгоритмов". Логически одно должно включать другое.
P.S. Стало понятно, автор имел ввиду «Алгоритмы работы
отделов» и «Алгоритмы взаимодействия отделов»

3. К достоинствам ДРАКОНа я считаю спорным относить субъективные характеристики по типу "простота в освоении", "лёгкость понимания".

4. Есть орфографические ошибки и опечатки на страницах 8 (в виду), 9 (прийдут), 13, 15, 17, 25, 46, 112, 117 (сходиться).
Мой внутренний педагог русского не может это просто так пропустить.

5. Далее хотелось бы обсудить дракон-схемы. Хоть я и не проходил никакой школы и званий не имею, но заметил моменты, которые заставляют усомниться в лёгкости понимания дракон-схем (опять же это моё мнение, необязательное к учёту).

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

В некоторых случаях, чтобы не быть голословным, я прикрепил свои варианты дракон-схемы того же самого алгоритма. Схемы были построены в DrakonHub, поскольку сами сотрудники использовали эту программу Степана Митькина (см. viewtopic.php?f=242&t=7167 ).

Это поможет как мне понять возможности редактора, так и сотрудникам увидеть эти возможности.

Чтобы мои полные дракон-схемы можно было открыть в DrakonHub и отредактировать, регистрируйтесь на DrakonHub, переходите по ссылке и копируйте схемы в своё рабочее
пространство: https://drakonhub.com/ide/doc/corgimama/26

Алгоритм "Подготовка и сдача табеля учёта рабочего времени по итогам работы за месяц"

Оригинал

Мое предложение

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

Алгоритм "Изменение штатного расписания"

- Первая икона Действие говорит «получить задачу», но название алгоритма предполагает, что задача уже получена. Соответственно, задачу можно просто определить в формальные параметры алгоритма. Если я правильно понимаю, слово «Задача» в этом блоке означает задание по изменению штатного расписания. Например, «Изменить количество штатных единиц охранников с 2 до 3».
- Следование правилам – это тоже не последовательное действие. Человек в начале алгоритма будет себя вести странно: «Вот я подействовал по правилам. Что дальше?». А дальше целый лес действий. Поэтому рекомендую правила внести также в формальные параметры, чтобы они, как и задание, сопровождали пользователя на протяжении всего алгоритма. У него всегда в руках будет листочек с заданием и книжка с регламентом.
- Иногда в дракон-схемах встречается излишняя конкретика, которая делает схему менее универсальной. Например, 2022 год в алгоритме 1 или название папки в алгоритме 10. Эстетически неприятно, когда ты живёшь в каком-нибудь 2030 году, а работаешь по старому алгоритму. Воленс-ноленс считаешь алгоритм «старьём». В этом алгоритме я бы избежал упоминания фамилий и имён сотрудников. Конечно, дай Бог, чтобы они проработали долго и счастливо, но в алгоритме ФИО исключает универсальность.
- Правые плечи развилок по сути содержат одинаковые инструкции просто на разном иерархическом уровне. Возможно на более низком уровне причину и решение разъяснит руководитель, а на высоком уровне никто ничего разъяснять не будет – ищи самостоятельно. Тем не менее формально инструкции одинаковы, я бы их объединил в одно плечо.

Алгоритм "Подбор персонала на вакантные должности"

- Единственное преимущество данной дракон-схемы перед аналогами – выделение смысловых частей с помощью силуэта. В остальном алгоритм остаётся тем же вытянутым шампуром. С одной стороны, это логично, ведь алгоритм в основе своей описывает бумажную волокиту. С другой стороны, момент отсева кандидатов не раскрыт. Какие причины отказа кандидату: несоответствие критериям, «дача ложных показаний», заключение о профессиональной непригодности по итогам собеседования, не прошёл проверку в службе безопасности. На эту же мысль также наводит использование слов, однокоренных словам «Контроль» и «Проверка».
- Первое Действие первой ветви самодостаточное, то есть достаточно одного этого действия и ветвь нечем будет дополнить. «Чтобы испечь хлеб, надо испечь хлеб». Возможные решения – переименование иконы Имя ветви, изменение иконы Действие, удаление иконы Действие.
- Последнее Действие ветви направлено всего на одно лицо. Ранее все действия совершались в отношении группы лиц. Какое лицо имеет ввиду последнее действие – неясно. Например, на должность охранника подали заявления 10 человек, недавно вернувшихся с армии. У двоих выявили криминальное прошлое, им отказали в приёме на работу. Осталось 8 человек, а процедуру приёма пройдёт только один.

Рассмотрим развилку одного из алгоритмов:

- Незначительное замечание. Ожидание подписания документов логичнее поместить в макроикону «цикл ЖДАТЬ». За период ожидания можно взять любой необходимый временной промежуток.

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

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

Алгоритм действий персонала службы обслуживания посетителей при утрате/порче номерка гардероба посетителем

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

Алгоритм действий персонала службы обслуживания посетителей при утрате/порче электронного браслета посетителем

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

Алгоритм действий администратора при оказании консультативной и навигационной помощи посетителям

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

Алгоритм оценки деятельности предоставления отчётов

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

Алгоритм продажи абонементов в кассах аквапарка посетителям

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

Алгоритм "Заключение договора поставки вычислительной и оргтехники

- Была проделана колоссальная работа и неловко даже выражать какие-то недовольства, тем более это очень важный бизнес-процесс. Тем не менее хотелось бы это сделать.
- Дракон-схема недостаточно компактно выглядит. Расстояния между иконами на мой взгляд не позволяют быстро воспринимать информацию. Ветвь «Получение проекта договора» считаю зря выделенной. Она не участвует в веточных циклах, содержит всего один гибридный цикл. Решение – поместить цикл в левое плечо развилки из прошлой ветки, а содержимое иконы Адрес сменить на «Согласование договора». Если важно оставить акцент на получении проекта, в плечо развилки можно добавить соответствующий Комментарий.
- Отмечу наглядное следование правилу «Чем правее – тем хуже» в ветви «Согласование договора».
- В ветви «Подписание договора» считаю подробными подписи в Комментариях и некоторых Действиях. Они как будто для тех, кто не следит за сюжетом.
- Просьба к помощнику генерального директора проверять почту должна быть периодична. Предлагаю сделать изменение подобное макроиконе «цикл ЖДАТЬ», добавленной ниже на этой же ветви. Мы попросили помощника, а он ждёт. А потом мы ждём, пока документ подпишут.
- Так как схема довольно широкая, мой вариант размещён на нескольких картинках, специально сокращёнными по вертикали для наглядности.
- Должен признаться, что в ветви «Подписание договора» нарушил принцип «Чем правее-тем хуже», чтобы дважды не обозначать переход на ветку «Выход». Мне это кажется более компактным вариантом, существенно не влияющим на сложность восприятия алгоритма.

Алгоритм "Заведение абонемента в ППС "Барс"

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

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

- Эти три алгоритма объединяет присутствие проверок. Последовательная цепочка действий логичная, если при всех проверках не было обнаружено недостатков. Но что нужно делать, если пост загрязнён? Наверное, обратиться к главному уборщику/санитару. Что делать, если не все ключи от помещения будут на месте? Обратиться к главе службы безопасности, например, или к администратору. То есть ценность алгоритма теряется, когда не предусмотрены такие случаи.
- В своём варианте я дополнил первый алгоритм одним решением всех проблем – «обратись к главе службы безопасности». Пусть дальше он решит, что с этим делать. Буду очень рад, если ранее неудачных проверок не возникало и не возникнет в будущем.

Алгоритмы "Начало работы и проверка работоспособности парковочной системы "JPark API", "Работа с журналом парковочной системы "JPark API", "Пропуск автомобиля оператором", "Обнуление чека", "Операции с кассой оплаты", "Установка режима "Множественный проезд", "Редактирование пропусков"

- Для комментирования была выбрана целая кипа дракон-схем, потому что их объединяет (на мой взгляд) одна система - парковочная система "JPark API".
- К построению схем замечаний не возникло, но возникли вопросы к смысловой составляющей каждой схемы. Первый и второй алгоритм начинаются с открытия интернет-браузера (google, yandex, мягко говоря, не совсем браузеры, но главное, чтобы подчинённый понимал о чём речь). Затем идёт действие «откройте ярлык программы…». Не понятно о какой программе идёт речь, надеюсь, на компьютере она всего одна и находится рядом с браузером. Первый алгоритм только после двух этих действий переходит в раздел «Мониторинг», а третьему алгоритму не надо ничего, чтобы перейти в этот раздел. Если автор схем устал повторяться, опять же можно создать отдельную маленькую дракон-схему «Запуск программы».
- Дракон-схемы с четвёртого по седьмой рисунки, полагаю, тоже применимы к программе «JPark API». И все они предполагают, что пользователь просмотрел алгоритмы 1 и 2, чтобы понимать, как открыть программу и какие вкладки, значки и поля имеются ввиду. Если говорить о свойствах алгоритма, считаю спорным присвоение свойства «Понятность». Для понимания последних алгоритмов необходимо рассмотреть первые, поэтому к письму прикреплено так много схем.

Алгоритм "Определение содержания остаточного активного хлора в воде бассейна (ГОСТ 18190-72)

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

Алгоритм "Подготовка к определению содержания остаточного активного хлора в воде бассейна"

- Логическая ошибка в развилке, которая обнаруживается на этапе проверки раствора соли Мора. Есть раствор или нет - налейте. В своём варианте я дополнил дракон-схему проверкой. Прошу прощения за чересчур краткий текст в схеме.

Алгоритм "Обработка результатов анализа содержания остаточного активного хлора в воде бассейна"

- Проблема выделена тёмно-красной областью. Почему-то обделён вниманием техник по водоподготовке. Если он в диспетчерской, ознакомить с результатами, а если нет – ничего страшного. Возникает вопрос, нужен ли техник по водоподготовке в этой схеме вообще? Нужно ли попросить диспетчера передать технику результаты?

Алгоритмы "Получение дистиллированной воды", "Приготовление 0,15%-ного раствора индикатора диэтилпарафенилендиамина сульфата", "Приготовление 10%-ного раствора серной кислоты", "Приготовление 0,8%-ного раствора трилона Б", "Приготовление 25%-ного раствора серной кислоты"

- В этом письме так много дракон-схем, но они объединены наличием процедуры получения дистиллированной воды. Сам алгоритм получения дистиллированной воды представлен на первом рисунке.
- Во всех алгоритмах получение дистиллированной воды фигурирует «в голой» развилке (отмечено тёмно-красной областью). Почему бы не перекинуть эту развилку в сам алгоритм получения воды? Тогда появится по-детски наивная в стиле Винни-Пуха проверка: «если в ёмкости есть вода – значит мы получили дистиллированную воду». Далее обсудим сам алгоритм получения дистиллированной воды.
- Если вдруг воду отключили во всём Белгороде на неделю (в Томске такое не редкость), бесконечное вопрошание лаборанта будет стоить ему нервов. Я о том, почему бы не использовать все возможности ДРАКОНа и не добавить макроикону «цикл ЖДАТЬ»? Она явно укажет работнику «нет воды – подожди».
- Действие «На этикетке ёмкости поставь дату, срок годности и подпись». Момент со сроком годности никак не обыгран в алгоритме. Вода в ёмкости изначально может быть с истёкшим сроком годности. ГОСТ Р 58144-2018 гласит, что срок хранения – не более семи дней.
- Мой вариант алгоритма представлен на последнем рисунке в этом письме.