Страница 2 из 4 ПерваяПервая 1234 ПоследняяПоследняя
Показано с 31 по 60 из 120
  1. #31
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от eliferov
    2. Как учить, переобучать, заменять людей, если существует только электронный вид документа "из которого естественным образом автоматизированно формируется модель услуги"? Далеко не все люди хорошо воспринимают текст с экрана.
    Если бы только это...
    Но вообще, все такие прожэкты ломаются на одном и том же процессе - управлении изменениями.
    Слегка драматизирую события (на самом деле все еще проще). Допустим хакер средней руки Гадюкин интересуется госуслугами. Он легким движением руки взламывает сервер регламентов и чего-то там меняет. После чего регламенты "естественным образом автоматизированно" генерируют новые услуги. Абзац, причем полный.
    А после вчерашей истории с взломом почтового сервера ФСО, история как-то не кажется маловероятной.

  2. #32
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию Еще 2 вопроса

    Цитата Сообщение от algol
    ...2. есть определенные требования к сотрудникам госуправления, в том числе умение работать с электронными документами. Есть действующий пример в Татарстане, там по другому не работают.
    1. Как скоро произойдет замена сегодняшних реальных кадров и куда их девать?
    2. Вопрос был не об умении, а о том, что читать инструкцию по работе, с экрана тяжело. Тем более, когда к ней часто приходится обращаться.
    С уважением Виталий.
    P.S. Я сам не люблю читать документы с экрана, да еще и есть соответствующий СанПин на продолжительность работы с компьютером.

  3. #33
    Член сообщества
    Регистрация
    15.12.2005
    Сообщений
    73

    По умолчанию На два вопроса один ответ

    Последние вопросы как-то вне зоны моей компетентности (безопасность и кадры). Чувствуется, что Вам уже надоело обсуждать этот бредовый текст.

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

  4. #34
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от algol
    Последние вопросы как-то вне зоны моей компетентности (безопасность и кадры). Чувствуется, что Вам уже надоело обсуждать этот бредовый текст...
    Правильно ли я понял, что условия труда "винтиков в госмашине" Вас не волнуют?
    То есть, модель должна предоставлять госуслуги неважно, какой ценой?

  5. #35
    Член сообщества
    Регистрация
    15.12.2005
    Сообщений
    73

    По умолчанию Елиферову

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

  6. #36
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от algol
    .... как надо делать определяет тот, кто никогда этого не делал (проектировщик моделей), а тот, который все делает становится тупым приложением к компьютеру, если он проявит инициативу, тут же будет наказан за непослушание." Это существующее положение дел.
    Новая модель позволит из "винтиков" сделать людей.
    Никак я не пойму, зачем Вы:
    1. Сначала описывает неправильную ситуацию ("как надо делать определяет тот, кто никогда этого не делал").
    2. Потом ее критикуете.
    3. Затем в исходном тексте заявляете: " пропадает разница между нормативным документом и моделью, это всего лишь разные формы представления одного и того же"
    - но это же обычный результат НОРМАЛЬНОГО проекта по регламентации бизнес-процессов. Если этого нет, значит внешние (или внутренние) бизнес-аналитики сработали безграмотно.
    При чем здесь "новая модель"?
    Такой результат можно получить разными способами для разных процессов.
    С уважением Виталий.

  7. #37
    Член сообщества
    Регистрация
    19.09.2006
    Сообщений
    260

    По умолчанию

    Цитата Сообщение от eliferov
    Никак я не пойму, зачем Вы:
    ...- но это же обычный результат НОРМАЛЬНОГО проекта по регламентации бизнес-процессов.
    Вот Болдин пишет:
    «На самом деле, главными результатами проекта являются:
    - Создание базы для регламентации, т.е.: понимания руководителями и сотрудниками что же они все таки делают, накопление и структурирование информационных материалов, пакет согласованных схем процессов.
    - Формирование группы людей которые могут на основе имеющейся информации разработать и согласовать регламенты, и обеспечить их исполнение в дальнейшем.»

    И я, с этим полностью согласен. Но, отсюда следует, что «НОРМАЛЬНЫЙ проект по регламентации бизнес-процессов» это игра слов. Есть ПРОЦЕСС регламентации бизнес-процессов. У него на выходе, периодически, появляются проекты по регламентации и ререгламентации отдельных БП. По моему так (С).

  8. #38
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от via
    .... Но, отсюда следует, что «НОРМАЛЬНЫЙ проект по регламентации бизнес-процессов» это игра слов. Есть ПРОЦЕСС регламентации бизнес-процессов. У него на выходе, периодически, появляются проекты по регламентации и ререгламентации отдельных БП. По моему так (С).
    Провильно ли я понял, что Регламент процесса N" появляется в результате "Процесса регламентации Процесса N"?
    Почему-то раньше я считал регламентацию - проектной работой. Каждый регламент - новый проект, если не делать его копи-пастом по стандартизованной схеме. Но такой "копи-паст" - далек от жизни и работать не будет.
    Можно, конечно, создать подразделение для которого "процесс регламентации" будет смыслом жизни, но лучше чтобы это делали сами руководители по установленным шаблонам и методикам.
    С уважением Виталий.

  9. #39
    Член сообщества
    Регистрация
    19.09.2006
    Сообщений
    260

    По умолчанию

    Цитата Сообщение от eliferov
    Провильно ли я понял, что Регламент процесса N" появляется в результате "Процесса регламентации Процесса N"?
    Не совсем. Можно, конечно, назвать процесс - «Регламентация процессов» (именно так – во множественном числе), но лучше «Совершенствование процессов».
    Цитата Сообщение от eliferov
    Можно, конечно, создать подразделение для которого "процесс регламентации" будет смыслом жизни, но лучше чтобы это делали сами руководители по установленным шаблонам и методикам.
    Именно так. Кайдзён рулит! Однако кто-то должен создавать шаблоны и методики. Как любой другой процесс, процесс «Совершенствование процессов» можно, полностью или частично, отдать на аутсорсинг, но его процессная, циклическая, итерационная природа ни куда не денется. Особенно циклическая (а значит процессная), итерационная природа деятельности «Совершенствование процессов» очевидна при реинжениренге\ререгламентации.

  10. #40
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

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

    2. Здесь видна четкая грань между трудом консультанта и менеджера: для первого регламент - это проект "пришел - написал - ушел", а для второго - процесс "разработка - корректировка - корректировка -..."
    Как говорят операционные менеджеры: нормативный документ устаревает уже в момент утверждения ... или даже раньше.
    Последний раз редактировалось А.Б.; 01.09.2010 в 13:21.

  11. #41
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от Александр Болдин
    1. via уловил самую суть: процесс регламентации.
    (не путать с процессом непрерывного совершенствования процессов).
    Наверное это и отличает организационно зрелую компанию - когда регламентация из набора микро-проектов становится процессом.
    Что-то, господа, ваши показания (или терминология) различаются....
    Не совсем. Можно, конечно, назвать процесс - «Регламентация процессов» (именно так – во множественном числе), но лучше «Совершенствование процессов».

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

  12. #42
    Член сообщества
    Регистрация
    19.09.2006
    Сообщений
    260

    По умолчанию

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

  13. #43
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

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

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

  14. #44
    Член сообщества
    Регистрация
    15.12.2005
    Сообщений
    73

    По умолчанию Елиферову №36

    Елиферов писал:«Затем в исходном тексте заявляете: "пропадает разница между нормативным документом и моделью, это всего лишь разные формы представления одного и того же"
    - но это же обычный результат НОРМАЛЬНОГО проекта по регламентации бизнес-процессов. Если этого нет, значит внешние (или внутренние) бизнес-аналитики сработали безграмотно. При чем здесь "новая модель"?

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

  15. #45
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от algol
    Мы должны договориться, что в существующей организации работ Нормативный документ (Регламент), его схема (Нормативная модель), и собственно программный модуль (Исполнительная модель) в большинстве случаев три большие разницы.
    1. Если я правильно понял, то это отправная точка: "As-Is - все плохо"
    Грамотность аналитиков предлагаю не рассматривать, она не имеет отношения к методике.
    2. Зато она имеет отношение к результату. Если регламенты создают недостаточно квалифицированные "регламентописатели", получаем ситуацию (см. п.1).
    Разница возникает по принципиальным соображениям. В Регламенте определяются общие принципы и ограничения, это текстовый документ. Нормативная модель - это в общем виде алгоритм. Исполнительная модель – программа. Бывают случаи, когда НМ и ИМ имеют связь от НМ к ИМ, но не наоборот.
    3. В каком регламенте появляется "разница по принципиальным соображениям"? Если в старом, то это не интересно, его нужно переделывать. Если в новом, то это проблема с квалификацией аналитика (регламентописателя).
    Отличие «Новой модели» от существующей состоит в том, что предлагается объединить Рег, НМ и ИМ в один механизм.
    4. Что в этом нового? Именно так работает грамотный аналитик: Разные способы отображения одного и того же процесса не должны противоречить друг другу. Именно поэтому большинство программных продуктов по моделированию БП имеют в своем составе модуль Publisher, для того, чтобы Модель и Регламент формировались из одного и того же источника и не могли иметь "разницу по принципиальным соображениям". А некоторые продукты тот же БП могут транслировать в BPEL, XPDL, BPMN. Получаем все три формы (Регламент, Модель и Исполняемый процесс) "разлитые из одного флакона". Изменение любой из форм через Модель транслируется в остальные.
    http://www.goodlancer.com/archives/5213
    С уважением Виталий.
    P.S. Это не реклама, я там давно не работаю. Просто этот "велосипед уже изобретен".

  16. #46
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    210

    По умолчанию

    Цитата Сообщение от Александр Болдин
    Это не разница в терминологии, а взгляд с разных уровней. Процесс регламентации существует практически в любой более-менее организованной компании, а вот процесс непрерывного совершенствования (кайдзен) - это уже следующий уровень. На который как в компьютерной игре нельзя выйти, не пройдя предыдущие уровни. Как бы ни хотелось.

    Применение технологии типа КАНБАН возможно только там где работает автоматизированная система, основанная на регламентах. Причем те регламенты написаны, внедрены и работают так, что их не видно - к ним обращаются в редких случаях, когда надо уточнить ответственность или когда меняется процесс.
    ... сделал бы здесь акцент… мне кажется, очень важная ремарка, речь действительно не о терминах, а об уровнях…
    … в ходе проекта по оптимизации процессов специалист, на основе своих знаний, начинает оперировать новыми сущностями (если он специалист, и если проект не ГосУслуги в РФ), вернее вновь появившимися метаданными о процессах, и они в свою очередь на следующем уровне развития также нуждаются в оптимизации… это как в природе ведь нет процессов умножения, это фактически есть оптимизированный человеком процесс сложения… а дальше степень, как оптимизация умножения… но чтобы работать со степенями необходимо изучить правила умножения и так далее … каждый последующий процесс оптимизирует предыдущий и через него влияет на исходный (базовый актив) … эта бесконечная гирлянда… аналогичная картина в реляционных базах данных, над плоскими таблицей первичного набора данных появляются метаданные о ключах, связях, процедурах, и на уровне управления базой данных вы уже не увидите вообще никакой, понятной «непосвященному» человеку информации... но, тем не менее, путем воздействия на нее (управления ею) зарплата каждому сотруднику начисляется аккуратно...

  17. #47
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию все просто ... только понять это не так просто

    Цитата Сообщение от GRIG
    ... сделал бы здесь акцент… мне кажется, очень важная ремарка, речь действительно не о терминах, а об уровнях…
    … в ходе проекта по оптимизации процессов специалист, на основе своих знаний, начинает оперировать новыми сущностями (если он специалист, и если проект не ГосУслуги в РФ), вернее вновь появившимися метаданными о процессах, и они в свою очередь на следующем уровне развития также нуждаются в оптимизации… это как в природе ведь нет процессов умножения, это фактически есть оптимизированный человеком процесс сложения… а дальше степень, как оптимизация умножения… но чтобы работать со степенями необходимо изучить правила умножения и так далее … каждый последующий процесс оптимизирует предыдущий и через него влияет на исходный (базовый актив) … эта бесконечная гирлянда… аналогичная картина в реляционных базах данных, над плоскими таблицей первичного набора данных появляются метаданные о ключах, связях, процедурах, и на уровне управления базой данных вы уже не увидите вообще никакой, понятной «непосвященному» человеку информации... но, тем не менее, путем воздействия на нее (управления ею) зарплата каждому сотруднику начисляется аккуратно...
    Согласен. Но не все так безнадежно.
    По проектированию баз данных: сейчас есть 3 основных технологии СУБД: реляционная, объектная и многомерная. Интересно, что промышленные СУБД используют не какую-то одну технологию, а комбинацию из основной и вспомогательной (например реляционная+объектная).
    Соответственно, аналитик-профи (в отличие от наскоро обученного использованию хранимых процедур и ключей программиста) использует комбинацию методов - понимая структуру задачи и структуру доступных методов. Поэтому разработанный обычным программистом модуль делает обратный инжиниринг 10 млн записей за сутки, а разработанный профи - за 10 минут. Иногда это бывает существенно :-)
    Кроме того, здесь есть особенность характерная для социальных систем: Если над сложной системой нет простой подсистемы управления, которую может понять 1 человек - основная система является неуправляемой.

    плюс
    вниманию Виталия:

    Регламент как исполнительный документ (по которому оценивается соответствие сотрудников) является результатом согласования интересов - зачастую противоположных. Другими словами - в регламенте есть схемная часть и компромиссная, учитывающая достигнутые в ходе разработки/согласования договоренности между исполнителями и контролем. Именно поэтому регламент процесса нельзя получить автогенерацией из схемы.
    Я понятно излагаю?

  18. #48
    Член сообщества
    Регистрация
    19.09.2006
    Сообщений
    260

    По умолчанию

    Цитата Сообщение от Александр Болдин
    Регламент как исполнительный документ (по которому оценивается соответствие сотрудников) является результатом согласования интересов - зачастую противоположных.
    В мемориз, однозначно!
    Самая суть! Одна из главных предпосылок, делающая регламентацию процессом!
    Во-первых, сразу становится понятным, что сам процесс согласования (регламентации) не менее, а может быть и более, важен, чем результат (регламент).
    Во-вторых - постоянно меняются условия согласования и интересы согласующих. Зачастую, это не позволяет поставить точку в создании регламента и заставляет пересогласовывать интересы снова и снова. Причины могут быть разными. Одни из самых распространённых:
    - ушёл петров, на его место пришёл сидоров. Произошло перераспределение весов участников;
    - сменился генерал – изменились приоритеты;
    - и т.д и т.п.

  19. #49
    Член сообщества
    Регистрация
    15.12.2005
    Сообщений
    73

    По умолчанию Елиферову №45

    >> 1. Если я правильно понял, то это отправная точка: "As-Is - все плохо"
    == Нет, это не плохо, а это так есть! В модели оценка хорошо-плохо отсутствует.
    >>2. Зато она (грамотность) имеет отношение к результату. Если регламенты создают недостаточно квалифицированные "регламентописатели", получаем ситуацию (см. п.1).
    == Зачем придумывать всякие дополнительные «если», тут и так есть что обсудить. В модели отсутствует понятие "регламентописатели".
    >> 3. В каком регламенте появляется "разница по принципиальным соображениям"? Если в старом, то это не интересно, его нужно переделывать.
    == Проблема "разницы по принципиальным соображениям" возникает в существующей методике, конкретный регламент в данном случае не обсуждается. В указанной Вами статье описывается технология, на основании применения, которого в конкретной работе мной был сделан вывод о наличии разрывности между Нормативным документом, Нормативной моделью и Исполняемой моделью.
    В статье прекрасно писана технология, только отсутствует существенный для госуслуг этап разработки нормативного документа, этот этап остается за рамками автоматизации. И если в «правильной» технологии регламентации разработка нормативного документа – завершающее действие, то при автоматизации госуслуг используется метод «от противного». :-)
    >> 4. Что в этом нового? Именно так работает грамотный аналитик: Разные способы отображения одного и того же процесса не должны противоречить друг другу. Именно поэтому большинство программных продуктов по моделированию БП имеют в своем составе модуль Publisher, для того, чтобы Модель и Регламент формировались из одного и того же источника и не могли иметь "разницу по принципиальным соображениям". А некоторые продукты тот же БП могут транслировать в BPEL, XPDL, BPMN. Получаем все три формы (Регламент, Модель и Исполняемый процесс) "разлитые из одного флакона". Изменение любой из форм через Модель транслируется в остальные.
    == Назову новое: отсутствует понятие трансляции между Нормативным документом, Нормативной моделью и Исполняемой моделью, вводится понятие Управление деятельностью вместо автоматизации процесса.
    С уважением, Александр.

  20. #50
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию Кроме шуток

    Почему системный аналитик глубоко задумывается, когда ему задают вопрос "Что такое бизнес-процесс?" Потому что он этот вопрос постояно задает сам себе и ответы у него постоянно разные.

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

  21. #51
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от algol
    В статье прекрасно писана технология, только отсутствует существенный для госуслуг этап разработки нормативного документа, этот этап остается за рамками автоматизации. И если в «правильной» технологии регламентации разработка нормативного документа – завершающее действие, то при автоматизации госуслуг используется метод «от противного».
    1. В статье показано получение Нормативного документа автоматом из Модели с помощью паблишера. Необходимость "разработки нормативного документа" отпадает, соответственно исчезают и противоречия между Моделью и Нормативным документом.
    2. Да, конечно, при автоматизации госуслуги обычно бывает какой-то нормативный документ, но при попытке создать из него модель, становится ясно, что документ нужно править. Кроме того, транслятор проверяет Модель на связность и непротиворечивость, отсутствие зацикливаний и т.д. Машина требует однозначной логики работы, поэтому нормативный документ иногода приходится менять по результатам трансляции. Таким образом устраняются все противоречия.
    ...отсутствует понятие трансляции между Нормативным документом, Нормативной моделью и Исполняемой моделью, вводится понятие Управление деятельностью вместо автоматизации процесса

    1. "трансляция" - эти автоматизированная процедура, которая и обеспечивает совпадение Модели, Нормативного документа и Исполняемого процесса.
    2. "Управление деятельностью" - это ручная процедура или автоматическая?
    3. Зачем "Управлять деятельностью" отдельного процесса? Лучше его автоматизировать и управлять совокупностью процессов. Труд исполнителя в автоматизированном процессе дешевле, чем ручное управление менеджером?
    С уважением Виталий.
    P.S. При формировании ответов, используйте, пожалуйста кнопку "тег цитаты" (крайняя справа в нижнем ряду), легче будет читать Ваши сообщения.

  22. #52
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    вниманию Виталия:
    Регламент как исполнительный документ (по которому оценивается соответствие сотрудников) является результатом согласования интересов - зачастую противоположных. Другими словами - в регламенте есть схемная часть и компромиссная, учитывающая достигнутые в ходе разработки/согласования договоренности между исполнителями и контролем. Именно поэтому регламент процесса нельзя получить автогенерацией из схемы.
    Я понятно излагаю?
    Вполне понятно, но .....
    Болдин писал:
    Почему системный аналитик глубоко задумывается, когда ему задают вопрос "Что такое бизнес-процесс?" Потому что он этот вопрос постояно задает сам себе и ответы у него постоянно разные.
    Для разных процессов требования к "компромиссной части" - разные. Если это технологический процесс, то компромиссов нет и быть не может. Утвержденную технологию надо исполнять.
    Если это регламент предоставления госуслуги, то компромиссная часть (по моему опыту) заключается только в сроках ответов и скорости пересылки (зависит от вида документов).
    Технология процесса, - получается автогенерацией из схемы.
    Исполнение процесса (экземпляр технологии), - является компромиссной по некоторым атрибутам.
    С уважением Виталий.

  23. #53
    Член сообщества
    Регистрация
    15.12.2005
    Сообщений
    73

    По умолчанию Елиферову

    == Я добросовестно пытался применять редактор и тэги при написании ответа, но на самом интересном месте происходит обновление сайта и набранное в поте лица пропадает с экрана. Наверное это происходит в момент публикации нового комментария. Я постараюсь выделить цитаты и ответы дополнительно.
    Ответы на 51
    Елиферов писал 1. В статье показано получение Нормативного документа автоматом из Модели с помощью паблишера. Необходимость "разработки нормативного документа" отпадает, соответственно исчезают и противоречия между Моделью и Нормативным документом.
    Ответ
    1 У Нормативного документа и Модели несколько разные задачи. Документ решает задачи организации в общем виде: кто, в какие сроки, что в общем виде, права, ответственность и т.п. Модель исполнительная – это конкретная реализация в этом месте и сейчас, завтра в другом месте МИ будет другой. Из той модели, о которой говорите Вы невозможно создать Нормативный документ, о котором говорю я. И это не ошибки «писателей», а ограничение метода.
    2. " отпадает, соответственно исчезают и противоречия» По правде говоря, кроме глупой таблицы (ARIS) и некоторого условно читаемого текста (БИГ) другого я не видел.
    Елиферов писал 2. Да, конечно, при автоматизации госуслуги обычно бывает какой-то нормативный документ, но при попытке создать из него модель, становится ясно, что документ нужно править.
    Ответ Править документ и модель нужно и в случаях изменения различных норм или видов и средств обеспечения услуги. Для конкретной организации эти изменения становятся постоянными, об этом уже упоминалось в текущем обсуждении.
    Елиферов писал Кроме того, транслятор проверяет Модель на связность и непротиворечивость, отсутствие зацикливаний и т.д. Машина требует однозначной логики работы, поэтому нормативный документ иногда приходится менять по результатам трансляции. Таким образом устраняются все противоречия.
    Ответ Мы видим, что из-за разного семантического уровня Нормативного документа и Исполнительной модели добиться соответствия можно только по некоторым узловым точкам.
    Елиферов писал 2. "Управление деятельностью" - это ручная процедура или автоматическая?
    Ответ Это не процедура. Содержание «Управления деятельностью» более подробно показано в параллельной ветке Методика моделирования госуслуг.
    Елиферов писал 3. Зачем "Управлять деятельностью" отдельного процесса? Лучше его автоматизировать и управлять совокупностью процессов. Труд исполнителя в автоматизированном процессе дешевле, чем ручное управление менеджером?
    Ответ Когда рассматриваем процесс, создается впечатление, что процесс - это все что нам нужно. На самом деле из рассмотрения выпадают организационные моменты создания и поддержания актуальности процесса (тут другие авторы уже писали об этом). Поэтому предлагается ввести понятие Управление деятельностью, которое будет содержать Организационную составляющую (на схеме 4 Управление структурами) и Реализационную составляющую (на схеме 4 Регулирование процессами, эта часть похожа на классические процессы). Более подробно Управление раскрыто в параллельной ветке про Методику…
    Ответ на 52
    Елиферов писал Если это регламент предоставления госуслуги, то компромиссная часть (по моему опыту) заключается только в сроках ответов и скорости пересылки (зависит от вида документов).
    Ответ Компромиссная часть какое-то странное понятие, похоже на коэффициент запаса (незнания, неопределенности). Мне кажется, если использовать многоуровневое представление о деятельности, то компромисс между нормативным документом и процессом пропадет.

    С уважением Александр.
    Последний раз редактировалось algol; 02.09.2010 в 14:37.

  24. #54
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от eliferov
    Вполне понятно, но ...
    1. Я ведь пишу про бизнес-процессы - в том числе, в приведенной тобой цитате.
    Но все равно:
    2. В технологическом процессе тоже есть изменяемая часть - любая спецификация позволяет отклоняться на какой-то %. Вот он и компромисс, в какую сторону отклоняться и на сколько?
    3. Я как бы не совсем из аула и знаю немного про госуслуги. Пример изменяемой части здесь - часы приема, которые могут зависеть от конкретной ситуации (ресурсы, особенности режима работы организации и т.п.), а следовательно от договоренности руководителей разного уровня.

  25. #55
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от algol
    1 У Нормативного документа и Модели несколько разные задачи. Документ решает задачи организации в общем виде: кто, в какие сроки, что в общем виде, права, ответственность и т.п. Модель исполнительная – это конкретная реализация в этом месте и сейчас, завтра в другом месте МИ будет другой. Из той модели, о которой говорите Вы невозможно создать Нормативный документ, о котором говорю я. И это не ошибки «писателей», а ограничение метода.
    2. " отпадает, соответственно исчезают и противоречия» По правде говоря, кроме глупой таблицы (ARIS) и некоторого условно читаемого текста (БИГ) другого я не видел.
    1. "завтра в другом месте" для других исполнителей потребуется другой Нормативный документ. Нормативный документ не меняется, - меняется экземпляр нормативного документа для конкретной реализации процесса в другом месте.
    2. Сожалею, что Вы не видели других реализаций регламентов. Неплохие регламенты кроме Casewise делает Business Studio. Регламенты сгенерированные из этих моделей не отличить от текстового документа, написанного человеком, но при условии хорошо настроенного шаблона публикации и четких правил (соглашения) по моделированию.
    Ответ Мы видим, что из-за разного семантического уровня Нормативного документа и Исполнительной модели добиться соответствия можно только по некоторым узловым точкам.

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

    Ответ Компромиссная часть какое-то странное понятие, похоже на коэффициент запаса (незнания, неопределенности). Мне кажется, если использовать многоуровневое представление о деятельности, то компромисс между нормативным документом и процессом пропадет.
    Здесь согласен. Вариация некоторых параметров модели не меняет модель.

    С уважением Виталий.

  26. #56
    Член сообщества
    Регистрация
    15.12.2005
    Сообщений
    73

    По умолчанию

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

  27. #57
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от algol
    Ответ Вообще-то в моем ответе был использован термин «Модель исполнительная». Которая, как справедливо Вы заметили, является экземпляром.
    У нас существует некоторое непонимание. Нормативный документ – это нечто похожее на закон, экземпляров не имеет. Исполнительная модель – это нечто похожее на конкретную инструкцию на конкретном рабочем месте, по определению имеет экземпляры....
    Тогда у нас действительно различается терминология:
    У меня Нормативный документ = Инструкция для конкретного исполнителя по реализации экземпляра процесса.
    У Вас Нормативный документ - головной первоисточник (референтная модель), из которого формируются экземпляры. Такой вариант тоже возможен и реализуем.
    С уважением Виталий.
    P.S. Все остальное - в личку.

  28. #58
    Член сообщества
    Регистрация
    30.07.2010
    Сообщений
    949

    По умолчанию

    Цитата Сообщение от algol
    Регламент предоставления услуги должен быть в электронном виде, но не в виде неструктурированного вордовского документа, а в виде некого структурированного документа из которого естественным образом автоматизированно формируется модель услуги и в соответствии с этой моделью происходит предоставление услуги и други необходимые виды деятельности.
    Интересно, а что в плане автоматизации процесса дает использование, например, XML, да еще при описании услуги? Можно, конечно, шапочку накидать, где будут обязательные поля и пр. - не промахнешься, заполнишь. Но что дает это в плане автоматизации процессов?

  29. #59
    Член сообщества
    Регистрация
    15.12.2005
    Сообщений
    73

    По умолчанию

    Padre Quart писал Но что дает это в плане автоматизации процессов?
    Ответ Например, XML-документ дает возможность естественным образом автоматизированно формировать модель услуги и в соответствии с этой моделью выполнять процесс предоставления услуги и другие необходимые виды деятельности, в отличие от неструктурированного документа.

  30. #60
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от Padre Quart
    Интересно, а что в плане автоматизации процесса дает использование, например, XML, да еще при описании услуги? Можно, конечно, шапочку накидать, где будут обязательные поля и пр. - не промахнешься, заполнишь. Но что дает это в плане автоматизации процессов?
    XML - это просто формат представления информации. Например, многие средства моделирования имеют возможность экспорта модели в XML формат. Пользователи могут ходить по линкам, смотреть документы, смотреть маршрутизацию, но не могут править модель, в отличии от исходной модели, менять которую может только админ.
    С уважением Виталий.

Страница 2 из 4 ПерваяПервая 1234 ПоследняяПоследняя

Ваши права

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