Показано с 31 по 60 из 120
-
31.08.2010, 13:02 #31
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от eliferov
Но вообще, все такие прожэкты ломаются на одном и том же процессе - управлении изменениями.
Слегка драматизирую события (на самом деле все еще проще). Допустим хакер средней руки Гадюкин интересуется госуслугами. Он легким движением руки взламывает сервер регламентов и чего-то там меняет. После чего регламенты "естественным образом автоматизированно" генерируют новые услуги. Абзац, причем полный.
А после вчерашей истории с взломом почтового сервера ФСО, история как-то не кажется маловероятной.
-
31.08.2010, 13:15 #32
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Еще 2 вопроса
Сообщение от algol
2. Вопрос был не об умении, а о том, что читать инструкцию по работе, с экрана тяжело. Тем более, когда к ней часто приходится обращаться.
С уважением Виталий.
P.S. Я сам не люблю читать документы с экрана, да еще и есть соответствующий СанПин на продолжительность работы с компьютером.
-
31.08.2010, 14:16 #33
- Регистрация
- 15.12.2005
- Сообщений
- 73
На два вопроса один ответ
Последние вопросы как-то вне зоны моей компетентности (безопасность и кадры). Чувствуется, что Вам уже надоело обсуждать этот бредовый текст.
Давайте сменим тему.
Есть некая методика методика моделирования деятельности на примере госуслуг, в которой сделана попытка реализации четвертого этапа автоматизации регламентов.
-
31.08.2010, 16:38 #34
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Сообщение от algol
То есть, модель должна предоставлять госуслуги неважно, какой ценой?
-
31.08.2010, 17:30 #35
- Регистрация
- 15.12.2005
- Сообщений
- 73
Елиферову
С точностью до наоборот.
В Тексте написано " Кроме этого происходит раделение труда: как надо делать определяет тот, кто никогда этого не делал (проектировщик моделей), а тот, который все делает становится тупым приложением к компьютеру, если он проявит инициативу, тут же будет наказан за непослушание." Это существующее положение дел.
Новая модель позволит из "винтиков" сделать людей.
-
31.08.2010, 17:53 #36
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Сообщение от algol
1. Сначала описывает неправильную ситуацию ("как надо делать определяет тот, кто никогда этого не делал").
2. Потом ее критикуете.
3. Затем в исходном тексте заявляете: " пропадает разница между нормативным документом и моделью, это всего лишь разные формы представления одного и того же"
- но это же обычный результат НОРМАЛЬНОГО проекта по регламентации бизнес-процессов. Если этого нет, значит внешние (или внутренние) бизнес-аналитики сработали безграмотно.
При чем здесь "новая модель"?
Такой результат можно получить разными способами для разных процессов.
С уважением Виталий.
-
01.09.2010, 11:31 #37
- Регистрация
- 19.09.2006
- Сообщений
- 260
Сообщение от eliferov
«На самом деле, главными результатами проекта являются:
- Создание базы для регламентации, т.е.: понимания руководителями и сотрудниками что же они все таки делают, накопление и структурирование информационных материалов, пакет согласованных схем процессов.
- Формирование группы людей которые могут на основе имеющейся информации разработать и согласовать регламенты, и обеспечить их исполнение в дальнейшем.»
И я, с этим полностью согласен. Но, отсюда следует, что «НОРМАЛЬНЫЙ проект по регламентации бизнес-процессов» это игра слов. Есть ПРОЦЕСС регламентации бизнес-процессов. У него на выходе, периодически, появляются проекты по регламентации и ререгламентации отдельных БП. По моему так (С).
-
01.09.2010, 12:06 #38
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Сообщение от via
Почему-то раньше я считал регламентацию - проектной работой. Каждый регламент - новый проект, если не делать его копи-пастом по стандартизованной схеме. Но такой "копи-паст" - далек от жизни и работать не будет.
Можно, конечно, создать подразделение для которого "процесс регламентации" будет смыслом жизни, но лучше чтобы это делали сами руководители по установленным шаблонам и методикам.
С уважением Виталий.
-
01.09.2010, 13:04 #39
- Регистрация
- 19.09.2006
- Сообщений
- 260
Сообщение от eliferov
Сообщение от eliferov
-
01.09.2010, 13:13 #40
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
1. via уловил самую суть: процесс регламентации.
(не путать с процессом непрерывного совершенствования процессов).
Наверное это и отличает организационно зрелую компанию - когда регламентация из набора микро-проектов становится процессом. При этом меняется как деятельность, так и механизмы контроля.
Без ложной скромности скажу, что в моей компании действует регламент этого процесса и есть сформированный по данному регламенту план разработки нормативных документов.
2. Здесь видна четкая грань между трудом консультанта и менеджера: для первого регламент - это проект "пришел - написал - ушел", а для второго - процесс "разработка - корректировка - корректировка -..."
Как говорят операционные менеджеры: нормативный документ устаревает уже в момент утверждения ... или даже раньше.Последний раз редактировалось А.Б.; 01.09.2010 в 13:21.
-
01.09.2010, 15:05 #41
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Сообщение от Александр Болдин
Не совсем. Можно, конечно, назвать процесс - «Регламентация процессов» (именно так – во множественном числе), но лучше «Совершенствование процессов».
Я называю это поддержание документации в актуальном состоянии и это прямая обязанность того, кто этот документ разрабатывал (если он внутренний) или того, для кого документ разработан (заказчик документа, исполнитель процесса и т.д.).
С уважением Виталий.
-
01.09.2010, 15:32 #42
- Регистрация
- 19.09.2006
- Сообщений
- 260
Сообщение от eliferov
"Поддержание документации в актуальном состоянии», у меня ассоциируется с ситуацией, когда «документированная процедура», регламентирующая некий участок работ, так и будет «документированной процедурой», даже тогда, кода это не удобно. Процесс же … ну хай будэ, регламентации, подразумевает, что, если участок должен быть регламентирован, а форма «документированная процедура» себя не оправдала, мы пробуем другие формы. Вешаем на стену плакат с «делай раз, делай два», или придумываем, какую ни будь, хейдзунку с канбанами.
-
01.09.2010, 15:53 #43
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Это не разница в терминологии, а взгляд с разных уровней. Процесс регламентации существует практически в любой более-менее организованной компании, а вот процесс непрерывного совершенствования (кайдзен) - это уже следующий уровень. На который как в компьютерной игре нельзя выйти, не пройдя предыдущие уровни. Как бы ни хотелось.
Применение технологии типа КАНБАН возможно только там где работает автоматизированная система, основанная на регламентах. Причем те регламенты написаны, внедрены и работают так, что их не видно - к ним обращаются в редких случаях, когда надо уточнить ответственность или когда меняется процесс.
-
01.09.2010, 17:22 #44
- Регистрация
- 15.12.2005
- Сообщений
- 73
Елиферову №36
Елиферов писал:«Затем в исходном тексте заявляете: "пропадает разница между нормативным документом и моделью, это всего лишь разные формы представления одного и того же"
- но это же обычный результат НОРМАЛЬНОГО проекта по регламентации бизнес-процессов. Если этого нет, значит внешние (или внутренние) бизнес-аналитики сработали безграмотно. При чем здесь "новая модель"?
Мы должны договориться, что в существующей организации работ Нормативный документ (Регламент), его схема (Нормативная модель), и собственно программный модуль (Исполнительная модель) в большинстве случаев три большие разницы. Грамотность аналитиков предлагаю не рассматривать, она не имеет отношения к методике. Разница возникает по принципиальным соображениям. В Регламенте определяются общие принципы и ограничения, это текстовый документ. Нормативная модель - это в общем виде алгоритм. Исполнительная модель – программа. Бывают случаи, когда НМ и ИМ имеют связь от НМ к ИМ, но не наоборот.
Отличие «Новой модели» от существующей состоит в том, что предлагается объединить Рег, НМ и ИМ в один механизм.
-
01.09.2010, 19:45 #45
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Сообщение от algol
Грамотность аналитиков предлагаю не рассматривать, она не имеет отношения к методике.
Разница возникает по принципиальным соображениям. В Регламенте определяются общие принципы и ограничения, это текстовый документ. Нормативная модель - это в общем виде алгоритм. Исполнительная модель – программа. Бывают случаи, когда НМ и ИМ имеют связь от НМ к ИМ, но не наоборот.
Отличие «Новой модели» от существующей состоит в том, что предлагается объединить Рег, НМ и ИМ в один механизм.
http://www.goodlancer.com/archives/5213
С уважением Виталий.
P.S. Это не реклама, я там давно не работаю. Просто этот "велосипед уже изобретен".
-
02.09.2010, 00:39 #46Сообщение от Александр Болдин
… в ходе проекта по оптимизации процессов специалист, на основе своих знаний, начинает оперировать новыми сущностями (если он специалист, и если проект не ГосУслуги в РФ), вернее вновь появившимися метаданными о процессах, и они в свою очередь на следующем уровне развития также нуждаются в оптимизации… это как в природе ведь нет процессов умножения, это фактически есть оптимизированный человеком процесс сложения… а дальше степень, как оптимизация умножения… но чтобы работать со степенями необходимо изучить правила умножения и так далее … каждый последующий процесс оптимизирует предыдущий и через него влияет на исходный (базовый актив) … эта бесконечная гирлянда… аналогичная картина в реляционных базах данных, над плоскими таблицей первичного набора данных появляются метаданные о ключах, связях, процедурах, и на уровне управления базой данных вы уже не увидите вообще никакой, понятной «непосвященному» человеку информации... но, тем не менее, путем воздействия на нее (управления ею) зарплата каждому сотруднику начисляется аккуратно...
-
02.09.2010, 08:46 #47
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
все просто ... только понять это не так просто
Сообщение от GRIG
По проектированию баз данных: сейчас есть 3 основных технологии СУБД: реляционная, объектная и многомерная. Интересно, что промышленные СУБД используют не какую-то одну технологию, а комбинацию из основной и вспомогательной (например реляционная+объектная).
Соответственно, аналитик-профи (в отличие от наскоро обученного использованию хранимых процедур и ключей программиста) использует комбинацию методов - понимая структуру задачи и структуру доступных методов. Поэтому разработанный обычным программистом модуль делает обратный инжиниринг 10 млн записей за сутки, а разработанный профи - за 10 минут. Иногда это бывает существенно :-)
Кроме того, здесь есть особенность характерная для социальных систем: Если над сложной системой нет простой подсистемы управления, которую может понять 1 человек - основная система является неуправляемой.
плюс
вниманию Виталия:
Регламент как исполнительный документ (по которому оценивается соответствие сотрудников) является результатом согласования интересов - зачастую противоположных. Другими словами - в регламенте есть схемная часть и компромиссная, учитывающая достигнутые в ходе разработки/согласования договоренности между исполнителями и контролем. Именно поэтому регламент процесса нельзя получить автогенерацией из схемы.
Я понятно излагаю?
-
02.09.2010, 10:41 #48
- Регистрация
- 19.09.2006
- Сообщений
- 260
Сообщение от Александр Болдин
Самая суть! Одна из главных предпосылок, делающая регламентацию процессом!
Во-первых, сразу становится понятным, что сам процесс согласования (регламентации) не менее, а может быть и более, важен, чем результат (регламент).
Во-вторых - постоянно меняются условия согласования и интересы согласующих. Зачастую, это не позволяет поставить точку в создании регламента и заставляет пересогласовывать интересы снова и снова. Причины могут быть разными. Одни из самых распространённых:
- ушёл петров, на его место пришёл сидоров. Произошло перераспределение весов участников;
- сменился генерал – изменились приоритеты;
- и т.д и т.п.
-
02.09.2010, 11:28 #49
- Регистрация
- 15.12.2005
- Сообщений
- 73
Елиферову №45
>> 1. Если я правильно понял, то это отправная точка: "As-Is - все плохо"
== Нет, это не плохо, а это так есть! В модели оценка хорошо-плохо отсутствует.
>>2. Зато она (грамотность) имеет отношение к результату. Если регламенты создают недостаточно квалифицированные "регламентописатели", получаем ситуацию (см. п.1).
== Зачем придумывать всякие дополнительные «если», тут и так есть что обсудить. В модели отсутствует понятие "регламентописатели".
>> 3. В каком регламенте появляется "разница по принципиальным соображениям"? Если в старом, то это не интересно, его нужно переделывать.
== Проблема "разницы по принципиальным соображениям" возникает в существующей методике, конкретный регламент в данном случае не обсуждается. В указанной Вами статье описывается технология, на основании применения, которого в конкретной работе мной был сделан вывод о наличии разрывности между Нормативным документом, Нормативной моделью и Исполняемой моделью.
В статье прекрасно писана технология, только отсутствует существенный для госуслуг этап разработки нормативного документа, этот этап остается за рамками автоматизации. И если в «правильной» технологии регламентации разработка нормативного документа – завершающее действие, то при автоматизации госуслуг используется метод «от противного». :-)
>> 4. Что в этом нового? Именно так работает грамотный аналитик: Разные способы отображения одного и того же процесса не должны противоречить друг другу. Именно поэтому большинство программных продуктов по моделированию БП имеют в своем составе модуль Publisher, для того, чтобы Модель и Регламент формировались из одного и того же источника и не могли иметь "разницу по принципиальным соображениям". А некоторые продукты тот же БП могут транслировать в BPEL, XPDL, BPMN. Получаем все три формы (Регламент, Модель и Исполняемый процесс) "разлитые из одного флакона". Изменение любой из форм через Модель транслируется в остальные.
== Назову новое: отсутствует понятие трансляции между Нормативным документом, Нормативной моделью и Исполняемой моделью, вводится понятие Управление деятельностью вместо автоматизации процесса.
С уважением, Александр.
-
02.09.2010, 11:37 #50
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Кроме шуток
Почему системный аналитик глубоко задумывается, когда ему задают вопрос "Что такое бизнес-процесс?" Потому что он этот вопрос постояно задает сам себе и ответы у него постоянно разные.
Когда я говорю на очередном совещании по оргструктуре, что бизнес-процесс более стабилен чем элемент структуры ... это не совсем так. Стабильной является модель процесса, причем на достаточно высоком уровне - там где она становится абстрактной. На уровне конкретики в модели процесса надо учитывать распределение ответственности
Программисты эту мысль улавливают сразу - они знают разницу между классом и экземпляром класса. Менеджеры кажется эту мысль не поймут никогда - они могут с ней только согласиться (поверить).
-
02.09.2010, 12:10 #51
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Сообщение от algol
2. Да, конечно, при автоматизации госуслуги обычно бывает какой-то нормативный документ, но при попытке создать из него модель, становится ясно, что документ нужно править. Кроме того, транслятор проверяет Модель на связность и непротиворечивость, отсутствие зацикливаний и т.д. Машина требует однозначной логики работы, поэтому нормативный документ иногода приходится менять по результатам трансляции. Таким образом устраняются все противоречия.
...отсутствует понятие трансляции между Нормативным документом, Нормативной моделью и Исполняемой моделью, вводится понятие Управление деятельностью вместо автоматизации процесса
1. "трансляция" - эти автоматизированная процедура, которая и обеспечивает совпадение Модели, Нормативного документа и Исполняемого процесса.
2. "Управление деятельностью" - это ручная процедура или автоматическая?
3. Зачем "Управлять деятельностью" отдельного процесса? Лучше его автоматизировать и управлять совокупностью процессов. Труд исполнителя в автоматизированном процессе дешевле, чем ручное управление менеджером?
С уважением Виталий.
P.S. При формировании ответов, используйте, пожалуйста кнопку "тег цитаты" (крайняя справа в нижнем ряду), легче будет читать Ваши сообщения.
-
02.09.2010, 12:19 #52
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
вниманию Виталия:
Регламент как исполнительный документ (по которому оценивается соответствие сотрудников) является результатом согласования интересов - зачастую противоположных. Другими словами - в регламенте есть схемная часть и компромиссная, учитывающая достигнутые в ходе разработки/согласования договоренности между исполнителями и контролем. Именно поэтому регламент процесса нельзя получить автогенерацией из схемы.
Я понятно излагаю?
Болдин писал:
Почему системный аналитик глубоко задумывается, когда ему задают вопрос "Что такое бизнес-процесс?" Потому что он этот вопрос постояно задает сам себе и ответы у него постоянно разные.
Если это регламент предоставления госуслуги, то компромиссная часть (по моему опыту) заключается только в сроках ответов и скорости пересылки (зависит от вида документов).
Технология процесса, - получается автогенерацией из схемы.
Исполнение процесса (экземпляр технологии), - является компромиссной по некоторым атрибутам.
С уважением Виталий.
-
02.09.2010, 13:47 #53
- Регистрация
- 15.12.2005
- Сообщений
- 73
Елиферову
== Я добросовестно пытался применять редактор и тэги при написании ответа, но на самом интересном месте происходит обновление сайта и набранное в поте лица пропадает с экрана. Наверное это происходит в момент публикации нового комментария. Я постараюсь выделить цитаты и ответы дополнительно.
Ответы на 51
Елиферов писал 1. В статье показано получение Нормативного документа автоматом из Модели с помощью паблишера. Необходимость "разработки нормативного документа" отпадает, соответственно исчезают и противоречия между Моделью и Нормативным документом.
Ответ
1 У Нормативного документа и Модели несколько разные задачи. Документ решает задачи организации в общем виде: кто, в какие сроки, что в общем виде, права, ответственность и т.п. Модель исполнительная – это конкретная реализация в этом месте и сейчас, завтра в другом месте МИ будет другой. Из той модели, о которой говорите Вы невозможно создать Нормативный документ, о котором говорю я. И это не ошибки «писателей», а ограничение метода.
2. " отпадает, соответственно исчезают и противоречия» По правде говоря, кроме глупой таблицы (ARIS) и некоторого условно читаемого текста (БИГ) другого я не видел.
Елиферов писал 2. Да, конечно, при автоматизации госуслуги обычно бывает какой-то нормативный документ, но при попытке создать из него модель, становится ясно, что документ нужно править.
Ответ Править документ и модель нужно и в случаях изменения различных норм или видов и средств обеспечения услуги. Для конкретной организации эти изменения становятся постоянными, об этом уже упоминалось в текущем обсуждении.
Елиферов писал Кроме того, транслятор проверяет Модель на связность и непротиворечивость, отсутствие зацикливаний и т.д. Машина требует однозначной логики работы, поэтому нормативный документ иногда приходится менять по результатам трансляции. Таким образом устраняются все противоречия.
Ответ Мы видим, что из-за разного семантического уровня Нормативного документа и Исполнительной модели добиться соответствия можно только по некоторым узловым точкам.
Елиферов писал 2. "Управление деятельностью" - это ручная процедура или автоматическая?
Ответ Это не процедура. Содержание «Управления деятельностью» более подробно показано в параллельной ветке Методика моделирования госуслуг.
Елиферов писал 3. Зачем "Управлять деятельностью" отдельного процесса? Лучше его автоматизировать и управлять совокупностью процессов. Труд исполнителя в автоматизированном процессе дешевле, чем ручное управление менеджером?
Ответ Когда рассматриваем процесс, создается впечатление, что процесс - это все что нам нужно. На самом деле из рассмотрения выпадают организационные моменты создания и поддержания актуальности процесса (тут другие авторы уже писали об этом). Поэтому предлагается ввести понятие Управление деятельностью, которое будет содержать Организационную составляющую (на схеме 4 Управление структурами) и Реализационную составляющую (на схеме 4 Регулирование процессами, эта часть похожа на классические процессы). Более подробно Управление раскрыто в параллельной ветке про Методику…
Ответ на 52
Елиферов писал Если это регламент предоставления госуслуги, то компромиссная часть (по моему опыту) заключается только в сроках ответов и скорости пересылки (зависит от вида документов).
Ответ Компромиссная часть какое-то странное понятие, похоже на коэффициент запаса (незнания, неопределенности). Мне кажется, если использовать многоуровневое представление о деятельности, то компромисс между нормативным документом и процессом пропадет.
С уважением Александр.Последний раз редактировалось algol; 02.09.2010 в 14:37.
-
02.09.2010, 13:57 #54
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от eliferov
Но все равно:
2. В технологическом процессе тоже есть изменяемая часть - любая спецификация позволяет отклоняться на какой-то %. Вот он и компромисс, в какую сторону отклоняться и на сколько?
3. Я как бы не совсем из аула и знаю немного про госуслуги. Пример изменяемой части здесь - часы приема, которые могут зависеть от конкретной ситуации (ресурсы, особенности режима работы организации и т.п.), а следовательно от договоренности руководителей разного уровня.
-
02.09.2010, 14:49 #55
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Сообщение от algol
2. Сожалею, что Вы не видели других реализаций регламентов. Неплохие регламенты кроме Casewise делает Business Studio. Регламенты сгенерированные из этих моделей не отличить от текстового документа, написанного человеком, но при условии хорошо настроенного шаблона публикации и четких правил (соглашения) по моделированию.
Ответ Мы видим, что из-за разного семантического уровня Нормативного документа и Исполнительной модели добиться соответствия можно только по некоторым узловым точкам.
Почему Вы так считаете? Я не вижу семантической разницы. Это опять разговор о том, что Вам не встречались хорошие средства формирования документа из модели.
Ответ Компромиссная часть какое-то странное понятие, похоже на коэффициент запаса (незнания, неопределенности). Мне кажется, если использовать многоуровневое представление о деятельности, то компромисс между нормативным документом и процессом пропадет.
С уважением Виталий.
-
02.09.2010, 15:20 #56
- Регистрация
- 15.12.2005
- Сообщений
- 73
Елиферов писал 1. "завтра в другом месте" для других исполнителей потребуется другой Нормативный документ. Нормативный документ не меняется, - меняется экземпляр нормативного документа для конкретной реализации процесса в другом месте.
Ответ Вообще-то в моем ответе был использован термин «Модель исполнительная». Которая, как справедливо Вы заметили, является экземпляром.
У нас существует некоторое непонимание. Нормативный документ – это нечто похожее на закон, экземпляров не имеет. Исполнительная модель – это нечто похожее на конкретную инструкцию на конкретном рабочем месте, по определению имеет экземпляры.
Елиферов писал 2. Сожалею, что Вы не видели других реализаций регламентов.
Ответ Мы оба, сожалеем! Может быть, глянуть хоть краем глаза поможете?
Елиферов писал Почему Вы так считаете? Я не вижу семантической разницы. Это опять разговор о том, что Вам не встречались хорошие средства формирования документа из модели.
Ответ Тут я согласиться не могу, но только, если Вы сможете меня убедить примером.
С уважением Александр.
-
02.09.2010, 16:27 #57
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Сообщение от algol
У меня Нормативный документ = Инструкция для конкретного исполнителя по реализации экземпляра процесса.
У Вас Нормативный документ - головной первоисточник (референтная модель), из которого формируются экземпляры. Такой вариант тоже возможен и реализуем.
С уважением Виталий.
P.S. Все остальное - в личку.
-
02.09.2010, 16:55 #58
- Регистрация
- 30.07.2010
- Сообщений
- 949
Сообщение от algol
-
02.09.2010, 17:18 #59
- Регистрация
- 15.12.2005
- Сообщений
- 73
Padre Quart писал Но что дает это в плане автоматизации процессов?
Ответ Например, XML-документ дает возможность естественным образом автоматизированно формировать модель услуги и в соответствии с этой моделью выполнять процесс предоставления услуги и другие необходимые виды деятельности, в отличие от неструктурированного документа.
-
02.09.2010, 17:33 #60
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Сообщение от Padre Quart
С уважением Виталий.