DRAKON.SU

Текущее время: Вторник, 07 Апрель, 2020 22:22

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 27 ]  На страницу Пред.  1, 2
Автор Сообщение
СообщениеДобавлено: Понедельник, 28 Январь, 2013 11:33 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Да, интересно. Прежде всего потому, что доклад уже не реклама "чего-то, что где-то есть", а донесение, пусть не без спецметодов, но каких-то конкретных положений, которые здесь же и можно видеть. Главных вопросов к ним, по сути, два:

1. Если рассмотреть это:
Владимир Паронджанов писал(а):
...
• Исключая из рассмотрения декларативные знания, мы ограничиваемся только процедурными знаниями. Для простоты будем считать, что процедурные знания и алгоритмы — одно и то же.
...
с учётом реальности (отнюдь не программистской :wink:), то можно заметить, что от сущности предмета труда зависит и характер труда. Т.е. та самая процедура (в частном случае) или техпроцесс (в понимании технологической науки, т.е. система алгоритмов).


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

• Во многих случаях они не умеют выделять в этой технологии стандартные и нестандартные участки.

• Они не рассматривают процессы выработки управленческих решений как алгоритмические процессы. И не умеют описывать эти процессы в алгоритмической форме.

Почему?
Потому что существующие методы алгоритмизации слишком сложны. Они рассчитаны на интеллектуалов-программистов и недоступны для «народа».
...
нужно сказать, что не все существующие методы алгоритмизации таковы. :) Существуют такие методы, которые доступны человеку даже и "с н/з образованием". И этот человек их успешно применяет на своём рабочем месте, чтобы не соврать, уже не одно столетие... :wink:

Догадались, о ком я? Правильно - о диспетчере. Ну о и любом, кому приходится по любой должности, называющейся иначе, играть эту роль. Ведь он фактически превращает систему техпроцессов, назначенных на управляемые им производственные мощности, в алгоритмически строгую, "сериализует" её. Что и есть случай алгоритмизации... динамической, в реальном времени...
    Так ведь это дело интеллектуальное, информатизации поддаётся плохо? Правильно. Так и теория расписаний в её сегодняшнем состоянии утверждает... Но. Это не значит, что нельзя дать вообще никакую информатическую модель диспетчерской деятельности. Только вот процедурными знаниями тут не ограничишься... даже и в программистском смысле, т.е. включая и декларативные и локально-связующие...
Надо видеть объект диспетчеризации как систему. Тогда можно дать, например, такую модель: viewtopic.php?p=74506#p74506. И понятно, что роль языка типа ДРАКОНа здесь своя, частная - представлять то, что Закревский, скажем, называет "последовательными алгоритмами" - процедуру типа программной, выполняемую на одном РМ одним субъектом управления. И имеющую смысл отчуждаемой части знания об отдельной техоперации.
Тогда как уже техпроцессы (реальные, которые предмет стандартизации в ЕСТД) - это "параллельные алгоритмы" по Закревскому... И они не тождественны "бизнес-процессам". С чем связано, в частности, сказанное Дагаевым здесь: viewtopic.php?p=77548#p77548. Ну а предметно разница обсуждалась здесь: viewtopic.php?p=74705#p74705.

И тип схем, целостно описывающих, для техпроцесса уже другой. Его можно "алгорасшифровать" и на ДРАКОНе - но уже как систему процессов. И она-то уже действительно м.б. сложноватой... даже для человека с "законченным высшим"... :wink:
Но. Реальному пользователю это и не надо - он пользуется именно целостными моделями, типа сетевых графиков. А теорию расписаний неформально применяет силами своего аппарата мышления... :)
Можно ли ему помочь? Да. И это давно уже делается. Как в КУБе Усова... или расчётке Соболева...
    Что здесь важно? Исходят не из нотации - а из теории деятельности. Её элементы, поддающиеся информатизации, выражают как однозначные инструкции и, возможно, реализуют машинно. Связывать эти элементы в техпроцесс алгоритмизации - уже дело человека как интеллектуальной системы.
То, что я здесь использую Закревского - не означает, что согласен с его позицией по алгоритмизации. Первичные вопросы здесь: viewtopic.php?p=77561#p77561. Но их можно расширить и детализировать. И тогда получается, что теории деятельности целостной и здесь не возникает...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 30 Январь, 2013 01:31 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
СТРУКТУРИРОВАНИЕ АЛГОРИТМОВ ВЫРАБОТКИ УПРАВЛЕНЧЕСКИХ РЕШЕНИЙ (САВУР-ТЕХНОЛОГИЯ)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 30 Январь, 2013 11:55 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 4652
Откуда: Москва
Ильченко Эдуард писал(а):
СТРУКТУРИРОВАНИЕ АЛГОРИТМОВ ВЫРАБОТКИ УПРАВЛЕНЧЕСКИХ РЕШЕНИЙ (САВУР-ТЕХНОЛОГИЯ)

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


Речь всегда идет о разработке новых алгоритмов или доработке старых. При этом следует различать следующие случаи.

Случай 1

1. Чиновник работает в госструктуре АБВГД. Эта структура работает по алгоритму Х.
Х является неизвестной величиной в том смысле, что алгоритм нигде не описан. Он хранится только в головах сотрудников госструктуры АБВГД. Они изо дня в день выполняют этот алгоритм. Но не догадываются, что работают по алгоритму.

2. Пришел новый Руководитель. Он хочет оптимально реорганизовать госструктуру АБВГД. Для этого необходимо изобразить Х как бизнес-процесс. При традиционном подходе приглашают бизнес-консультантов (бизнес-аналитиков) и поручают им разработать бизнес-процессы, отображающие деятельность госструктуры АБВГД.

3. Недостатки такого подхода, в частности, описал alexus на нашем форуме.
Подчеркну следующее:

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

3.2. Разные консультанты выдают разные результаты.

3.3. Консультанты не являются сотрудниками АБВГД. Они не знают всех тонкостей и особенностей госструктуры АБВГД. Поэтому они создают продукт низкого качества.

3.4. Гитлеры приходят и уходят. А Руководитель остается. Именно Руководитель должен внедрять рекомендации заезжих варягов.

3.5. В сложных случаях Руководитель просто не в состоянии разобраться в созданном варягами проекте. Почему? Потому что он не Юлий Цезарь.

4. Описанную ситуацию нужно решительно менять. Разработку алгоритма Х должны выполнять не заезжие варяги, а свои люди, то есть сотрудники госструктуры АБВГД. Потому что они работают здесь с пеленок. И знают проблему изнутри. Как свои пять пальцев.

5. Правило.
Цитата:
Кто должен формализовать проблему?
Тот, кто обладает знаниями.
А не тот, кто познакомился с ней с чужих слов


6. На этом пути возникает проблема. Причем не простая. Трудность в том, что чиновники, работающие в госструктуре АБВГД, не знают, что такое алгоритм. Они никогда не видели живого алгоритма. И не знают с чем его едят.

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

8. В самую трудную минуту на помощь Руководителю подоспел Гостинец для Дракона.

9. С помощью Гостинца Руководитель быстро во всем разобрался.
Он пригласил Эдуарда Ильченко (или его помощников) и организовал обучение сотрудников госструктуры.
Проблема была быстро и успешно решена своими силами. Каким образом?

10. Руководитель лично освоил Гостинец. И добился того, чтобы Гостинец освоили его ближайшие помощники, руководители управлений и отделов Ведомства и другие сотрудники.

11. Под мудрым руководством Руководителя и под его неусыпным контролем сотрудники госструктуры АБВГД извлекли знания (с помощью Гостинца) из собственных голов и превратили их а в алгоритмы. Затем они (опять с помощью Гостинца) распечатали их на бумаге на принтерах формата А3.

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

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

14. Имеются (правда, непроверенные) сведения о том, что Руководителю настолько понравились результаты работ, что он велел — для распечатки дракон-схем — закупить принтеры формата А1.

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


Последний раз редактировалось Владимир Паронджанов Среда, 30 Январь, 2013 14:43, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 30 Январь, 2013 13:54 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Владимир Паронджанов писал(а):
Ильченко Эдуард писал(а):
СТРУКТУРИРОВАНИЕ АЛГОРИТМОВ ВЫРАБОТКИ УПРАВЛЕНЧЕСКИХ РЕШЕНИЙ (САВУР-ТЕХНОЛОГИЯ)

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


Речь всегда идет о разработке новых алгоритмов или доработке старых. При этом следует различать следующие случаи.

Случай 1

1. Чиновник работает в госструктуре АБВГД. Эта структура работает по алгоритму Х.
Х является неизвестной величиной в том смысле, что алгоритм нигде не описан. Он хранится только в головах сотрудников госструктуры АБВГД. Они изо дня в день выполняют этот алгоритм. Но не догадываются, что работают по алгоритму.

2. Пришел новый Руководитель. Он хочет оптимально реорганизовать госструктуру АБВГД. Для этого необходимо изобразить Х как бизнес-процесс. При традиционном подходе приглашают бизнес-консультантов (бизнес-аналитиков) и поручают им разработать бизнес-процессы, отображающие деятельность госструктуры АБВГД.

3. Недостатки такого подхода подробно описал alexus на нашем форуме. Повторю:
...
Усов описал нечто другое. Процитирую его словами:
alexus в viewtopic.php?p=69232#p69232 писал(а):
Владислав Жаринов писал(а):
Вот да, кстати, об этом:
alexus в viewtopic.php?p=69173#p69173 писал(а):
...
Если идти от жизни... Путь есть некоторая предметная область. С ней работают самые разные специалисты: аналитики, проектировщики, технологи, плановики, разработчики, те, кто занимается эксплуатацией... В чём различие всех этих специалистов?.. Очевидно, в точке зрения на предметную область, что определяется спецификой их работы, поставленными задачами, а значит и инструментами/оборудованием, языковыми различиями, наконец. Теперь мы хотим, чтобы все они использовали один и тот же язык?.. Но смогут ли технолог и бухгалтер, например, говорить на одном языке?.. А аналитик, проектировщик и разработчик?.. И вопрос не в том, графический это язык или нет, вопрос в том, надо ли вообще к этому стремиться?.. Может быть оставить возможность "сапожнику" и "пирожнику" говорить на своих языках... чтобы не остаться босым и с больным желудком?..
...
Насчёт точки зрения - реально так. Скажем, задачу, представленную в этой теме: viewtopic.php?f=86&t=3633 - я описывал на протяжении своего участия в "управлении качеством" дважды - с т. зр. менеджера проекта, как он определён в задаче, и менеджера по сбыту (на определённом этапе эти роли разделились - первый стал вести контракты, второй - заказчиков). И ясное дело, что описания получались разными, начиная с целевых установок... :wink:
Описание бизнес-процессов, по своей сути, антисистемно, поэтому обсуждать нет смысла.
Владислав Жаринов писал(а):
Насчёт языков - не получается ли тут подмены предмета по ходу изложения? Сначала говорим об одной предметке с т. зр. разных ролей - а затем вроде как о разных (и подразумевающих специфику содержания)?..
Подмена понятий может возникнуть, в случае, если нет понимания целого. Тогда частные точки зрения начинают претендовать на объективность. Что и происходит при описании бизнес-процессов...
Если же идти от понимания целого, то это целое проецируется на те или иные специализации без конфликтов. Каждая область, как ей и положено, использует свой инструментарий (свой язык, в том числе).
...


Последний раз редактировалось Владислав Жаринов Среда, 30 Январь, 2013 14:10, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 30 Январь, 2013 14:08 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Далее Усов уточнил понимание того, работает ли система АБВГД по алгоритму Х:
alexus в viewtopic.php?p=69234#p69234 писал(а):
... Реальная проблема в том, что начало работы схемы или метода отдельного элемента/объекта может начаться при одном состоянии системы, а завершиться уже в другом состоянии системы. Это накладывает определённые требования на переходные процессы. Ещё более трудная ситуация возникает в случае параллельной работы (одновременная обработка нескольких сообщений/событий/возмущений). Параллельные процессы могут ничего не узнать о смене состояния системы... Необходимо вводить правила и протоколы, например, нечто подобное требованиям ACID для транзакций в СУБД. Это большая тема, вряд ли она здесь будет уместной и интересной.
Владислав Жаринов писал(а):
И опять же получается - основа разработки - это граф ПМ системы, замкнутый на окружение. Возможно, также структурно детализированное в меру понимания сочинителя - но хотя бы законами отклика на воздействия системы заданное (передаточными функциями, алгопроцедурами тоже). Так?
Да, так... Любая система - это элементы и связи...
Владислав Жаринов писал(а):
Узлам графа (исполнителям) сопоставлены процедуры реакции. А в программируемой системе часть процедур (для машинных исполнителей) имеет вид программ. Так?
Реакции?.. Возмущения-реакции - это термины пограничного слоя система-внешняя среда. Внутри системы есть задания/вызовы методов, которые система выдаёт/активирует, в рамках предопределённых схем. Программ, в привычном виде, нет, есть инструменты.
...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Февраль, 2013 20:20 

Зарегистрирован: Вторник, 02 Октябрь, 2012 11:39
Сообщения: 29
А куда делась ветка с Гостинцем? Только утром ее просматривал... :shock:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 03 Февраль, 2013 20:24 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1061
Откуда: Россия, Чебоксары
SergeyNK писал(а):
А куда делась ветка с Гостинцем? Только утром ее просматривал... :shock:
Однако такие дела...


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 27 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2020, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB