Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по Business Studio

Облако терминов
12-процессная модель 4PL ACM Activity diagram AQPC ARIS ARIS 9 ARIS eEPC Balanced Scorecard Big Data & Analytic BMPN BPA BPEL BPM BPM accelerator BPM CBOK BPM-система BPM-системы BPMN BPMS BPR BPWin BS Portal BSC Business Intelligence Business Performance Management Business Performance Management (BPM) Business Process Management Business Process Management Systems Business Process Manager Business Rules Business Studio Business Studio 3.6 Business Studio 4 Business Studio 4.0 Business Studio Portal CA ERwin Data Modeler Case Management Casewise Casewise Corporate Modeler CFFC Corporate Modeler CPM CRM Decision Management DFD Digital Directum

Моделирование бизнес-процессов в нотации BPMN
Опрос

Вы используете

Библиотека

09.03.2011 15:27
  от автора
  Репин

Борьба процессов с бизнес-процессами - это Битва тигра с драконом

Оценки за материал: 3.67 (6)

Статья В.Г. Елиферова

«В битве тигра с драконом побеждает
мудрая обезьяна, сидящая на дереве»
Очень древняя китайская мудрость


Регулярно и достаточно давно, занимаясь моделированием, описанием и реинжинирингом бизнес-процессов, а также управленческим консалтингом по реструктуризации предприятий и разработкой и внедрением систем менеджмента качества, автор обратил внимание на тот интересный факт, что при наличии большого количества литературы, посвященной проблемам процессного подхода и бизнес-процессам, в этой литературе не дается четких определений: Что такое бизнес-процесс и чем он отличатся от процесса?
Регулярно и достаточно давно, занимаясь моделированием, описанием и реинжинирингом бизнес-процессов, а также управленческим консалтингом по реструктуризации предприятий и разработкой и внедрением систем менеджмента качества, автор обратил внимание на тот интересный факт, что при наличии большого количества литературы, посвященной проблемам процессного подхода и бизнес-процессам, в этой литературе не дается четких определений: Что такое бизнес-процесс и чем он отличатся от процесса?

Процессы и бизнес-процессы описывают разные службы организации (оргразвитие, ИТ-службы, финансовые службы, служба качества и т.д.). Эти процессы и бизнес-процессы каждая служба в своем проекте определяет по своему, строит в каждом проекте свою карту процессов или модель бизнес-процессов. При этом в роли «мудрой обезьяны» (см. эпиграф) чаще всего выступают IT-службы, поскольку модель бизнес-процессов создается, как правило, с использованием какого-либо программного продукта для моделирования или бизнес-процессы автоматизируются с помощью какого либо программного продукта (CRM, ERP). При этом очень часто IT-специалисты руководствуются рекомендациями: «Архитектура процессов должна обеспечить: увязывание процессов с архитектурой ИТ и приложениями, поскольку ИТ должны поддерживать настоящие и будущие процессы» ([1], стр. 114). То есть по мнению автора (а скорее всего переводчика), архитектура ИТ важнее процессов, реализующих бизнес, и процессы должны подстраиваться под архитектуру ИТ-сервисов, а не наоборот.
Тем не менее, руководствуясь таким переводом, сотрудники ИТ-сервисов начинают руководить проектом по созданию модели бизнеса.

То есть, объекты управления в организации выделяют и описывают не профессиональные менеджеры, а IT-специалисты, просто потому, что они лучше знают «птичьи языки» моделирования и программирования. Процессы, подпроцессы и бизнес-процессы, созданные IT-специалистами, в большей или меньшей степени дублируют друг друга, петляют, пересекаются, накладываются на содержимое, чуть более привычного термина «функции» и … окончательно запутывают сотрудников и руководителей организации, вместо того, чтобы помогать им. В результате, в организации приходят к выводу что от «процессов» и «бизнес-процессов» никакого толка, кроме затрат ресурсов на создание «красивых картинок».

Для чего нужна «Модель (карта) процессов (бизнес-процессов)»

Многократные опросы заказчиков привели автора к «крамольной мысли»: «Организации нужна не модель бизнес-процессов, а повышение эффективности работы и управления». Повышение же эффективности связано с изменением системы управления объектами организации и самих объектов. Вот здесь и кроется различие между бизнес-процессами, потому, что нельзя по одним и тем же требованиям создавать модели бизнес-процессов «Бюджетирование» и «Заключение договора» или «Закупки». Слишком это разные процессы, слишком разные требования предъявляются к эти бизнес-процессам с точки зрения их регламентации и предоставления информации. Для того, чтобы рассклассифицировать требования к бизнес-процессам необходимо выделить в организации основные фокус-группы потребителей информации от модели бизнес-процессов. Из опыта работы в проектах и перечитанной литературы по системам управления удалось выделить в организациях пять основных групп потребителей информации, которую может дать модель бизнес-процессов.

1. Топ-менеджмент организации (включая первое лицо)
2. Финансово- экономический блок (включая главного бухгалтера)
3. Руководители разных уровней (к этой группе могут относиться и некоторые топ-менеджеры)
4. Технологи (термин «Технологи» в данной статье употребляется в широком смысле этого слова, для обозначения всех специалистов организации создающие технологии работы, в том числе технологии финансового планирования, бухучета, работы с персоналом и т.д) и Исполнители
5. IT- специалисты.

Для того, чтобы модель бизнес-процессов отвечала всем требованиям заказчика, необходимо разобраться, какую информацию каждая из этих групп в организации хочет получить от модели.

Прежде чем перейти к рассмотрению информационных требований к модели бизнес-процессов со стороны различных групп потребителей, позволю себе напомнить, что термин «бизнес-процесс» используется и в области разработки и внедрения программных продуктов класса Workflow и Docflow. Прежде чем автоматизировать цепочку действий человека и компьютера, ее нужно описать в виде, понятном и бизнес-аналитику и программисту. Поэтому, вместе с информационной составляющей модели, должны рассматриваться и возможности, которые модели предоставляет для автоматизации деятельности сотрудников и руководителей. Поскольку внедрение средств автоматизации систем менеджмента актуально для организаций среднего и большого размера, то для некоторого упрощения примем, что рассматривается именно такая организация, где высшее руководство целесообразно рассматривать как объекты, управляющие достаточно большими бизнес-юнитами, имеющими свои задокументированные планы, бюджеты и отчеты о своей деятельности.


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

Автоматизация деятельности топ-менеджеров должна включать оперативное предоставление всей необходимой информации и аналитики для принятия управленческих решений, а также систему документооборота и контроля за исполнением планов, решений и поручений. То есть в качестве программных продуктов для автоматизации деятельности топ-менеджмента используются панели и аналитики класса BI (Business Intelligence), OLAP (Online Analytical Processing) или отчеты из корпоративных информационных систем (ERP), а также различные системы документооборота и контроля за исполнением поручений workflow и docflow.

Менеджеры финансово-экономического блока должны получить информацию о том, какие центры финансовой ответственности (ЦФО) или объекты для планирования и учета существуют в организации. Это необходимо для того, чтобы системы планирования, бюджетирования и управленческого учета совпадали с объектами управления и ответственными за эффективность этих объектов. То есть системы финансового планирования должна совпадать с реальной системой управления и давать точную информацию об эффективности процессов и бизнес-процессов.

Типичной проблемой, которая еще достаточно часто встречается в организациях, являются попытки совместить системы бюджетирования, бухгалтерского учета и управленческого учета или, что еще хуже, попытки менеджеров управлять по данным бухгалтерского учета, которые появляются в учетной системе с достаточно большим опозданием и часто бывают построены на основе бухгалтерских статей, без разнесения затрат на реальные объекты управления.
Как правило, деятельность финансово-экономического (и бухгалтерского) блоков бывает уже автоматизирована с помощью действующих учетных программ. Тем не менее, при построении или изменении системы управления часто приходится заново распределять и перераспределять функционал учетных систем. В реальной жизни автору однажды встретился случай, когда заказчик потребовал чтобы внедряемая биллинговая системы выполняла часть функционала бухгалтерской системы, например формирование Книги продаж. То есть, тщательно обоснованное распределение функций и бизнес-процессов между программными продуктами, автоматизирующими деятельность финансово-экономического блока, является одним из необходимых условий любого проекта автоматизации. А для этого придется провести моделирование бизнес-процессов, их анализ и распределение между системами. Анализ вариантов распределения функционала с помощью модели «на бумаге» обходится гораздо дешевле, чем переделка уже внедренного неоптимального решения.

Так же, как и топ-менеджеры, сотрудники финансово-экономического блока нуждаются в средствах автоматизации рутинной деятельности в части документооборота и контроля за исполнением принятых решений и поручений, что также реализовывается в системах класса workflow и docflow.
Руководители среднего звена, которые традиционно считают себя обделенными информацией о направлениях стратегического развития организации (экспертная оценка автора, что в 80% случаев руководители среднего звена управления жалуются на недостаток информации о перспективных планах руководства и неожиданных решениях, которые приходится исполнять в спешном порядке.), хотят получить от модели видение взаимосвязи целей и целевых показателей их процессов (проектов и подразделений) с всей системой целей организации, а также однозначное, задокументированное и утвержденное распределение ответственности, полномочий и взаимодействия которые должны быть подкреплены выделением соответствующих ресурсов всех необходимых видов. Цели и объекты планирования для руководителей неразрывно связаны с системой отчетности и показателями эффективности их управленческой деятельности, поэтому система отчетности руководителей среднего звена должна строиться с учетом выделенных объектов управления (процессов, проектов и т.д.) и входить в общую систему целей всей организации.

Автоматизация деятельности руководителей среднего звена похожа на автоматизацию для топ-менеджмента. Руководителям также нужен доступ к плановым и отчетным данным из информационно аналитической системы, доступ к системе документооборота и контроля за исполнением заданий и поручений.
Технологи – под этим термином мы подразумеваем огромный класс специалистов, которые создают в организации технологии и документируют их для того, чтобы исполнители имели под руками утвержденную технологию работы (обработки документов или приема заявок от людей и организаций и т.д.). Этим специалистам необходимо четкое распределение ответственности между исполнителями и руководителями, однозначные критерии по которым исполнители должны обращаться за решением к специалистам и руководителям, точные указания Кто решает данный класс проблем? Для того, чтобы можно было оценить эффективность технологии, разнесение затрат должно быть организовано с учетом выделенных объемов работ, последовательности операций и переделов отнесенных к одному технологическому процессу. Соответственно, при разработке и документировании технологических процессов необходимо предусмотреть точки сбора и обработки первичной информации о деятельности отдельных процессов из которой должна сложиться общая система отчетности организации.

Автоматизировать деятельность технологов нелегко, поскольку очень часто сами содержание технологий имеет элементы творческих и нестандартных
решений. То есть автоматизация творческих процессов созидания невозможна, но можно автоматизировать создание технологических документов в которые, по определенным правилам будет автоматически (или полуавтоматически) перенесена технология. При этом, очень часто, технологии необходимо сопровождать графическим изображением в виде блок-схемы, обеспечивать их размещение на интранет-портале или на рабочих местах исполнителей. Спектр информационных продуктов, с которыми приходится работать технологам, чрезвычайно широк и разнообразен. Это и системы класса CRM (Customers Relationship Management - Управление взаимоотношениями с клиентами), и WMS (Warehouse Management System — система управления складом), и различные MES-системы (Manufacturing
Execution System - автоматизированная система управления и оптимизации производственной деятельности).

Очень часто технологи работают совместно с бизнес-аналитиками. Такой союз оправдан в том случае, когда требуется при разработке технологического процесса учесть его взаимодействие с другими процессами, согласовать между собой различные процессы и оптимально выстроить всю систему деятельности организации. К сожалению такое встречается не часто. Иногда каждый из технологов создает свою, «отдельно взятую» технологию, которая оптимально работает в том случае, когда соседям приходится работать для ее обеспечения в неоптимальном для них режиме.

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

Роль IT-специалистов в обеспечении необходимой информацией всех вышеупомянутых категорий сотрудников, трудно переоценить. Именно им приходится обеспечивать работу всех информационно-аналитических систем организации и … регулярно перенастраивать отчеты и отчетные формы, которые поступают руководству, поскольку исчерпывающих отчетов не бывает, а новшества и идеи о взгляде на организацию в «другом разрезе» осеняют руководителей почти непрерывно. Кроме того, именно им приходится настраивать и перенастраивать многочисленные цепочки workflow и docflow, которые присутствуют в любой информационной системе, будь то сложный ERP-продукт или самая простейшая система документооборота и поручений с использованием Outlook Express. Для их работы характерно то, что при малейшем изменении технологии работы и/или обработки информации им приходится заново настраивать последовательность работ, тщательно отслеживать атрибуты каждого объекта автоматизации, безошибочно переносить новые технологические процессы (ведь пишут их не они, а технологи и бизнес-аналитики).

Автоматизация этой сложной, часто рутинной, деятельности возможна, если формат описания технологии бизнес-процессов, который используют технологи и бизнес-аналитики является достаточно полным и понятным для преобразования их «человеческих» блок-схем, в «программные» исполняемые бизнес-процессы. Например в BizTalk, XPDL или BPEL. То есть в требования к бизнес-моделированию этих процессов необходимо внести простую и быструю трансляцию блок-схем в исполняемый язык программных продуктов workflow.

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

4. Иерархические системы обычно состоят из немногих типов подсистем по-разному скомбинированных и организованных.
Совершенно аналогично каждая организация состоит из четырех основных видов подсистем (процессов или бизнес-процессов) «по разному скомбинированных и организованных».


Рис. 2 . Виды процессов, из которых состоит деятельность каждой организации. Для упрощения на данном рисунке не показаны Исполняемые процессы.

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

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

2. Технологические процессы – выделенная деятельность, результатом которой являются основные продукты, услуги или ресурсы. При этом разделение на основные и вспомогательные процессы носит достаточно условный характер. Например в отделе кадров часто существует документированный технологический процесс «Порядок приема на работу», который предназначен для поставки ресурса под названием сотрудники для всех подразделений и процессов организации.

Основными характерными чертами технологических процессов являются следующие:
• технологические процессы должны иметь владельцев, несущих ответственность за их результативность и эффективность и предоставляющих отчетность вышестоящему руководству;
• они предназначены для документирования и регламентирования уникальных способов работы (технологий);
• они должны совпадать со стадиями технологического процесса, на которые производится разнесение затрат в бухучете,
• виды деятельности, из которых они состоят должны соответствовать функциям и задачам, закрепленным в должностных инструкциях, положениях о подразделениях и других нормативных документах;
• каждый из видов деятельности (операций) из которых они состоят, должен быть закреплен за конкретным сотрудником;
• каждый процесс должен иметь «поставщиков» и «входы», а также «потребителей» и «выходы»;

3. Процессы-процедуры – в ряде случаев в организациях существуют процессы, у которых невозможно напрямую найти владельца, или лицо, ответственное за результат. Такие процессы описываются процедурами, которые также регламентируют цепочки видов деятельности, но эти процедуры используются в организации многократно, по одному и тому же регламенту. Нельзя выделить одного владельца такого бизнес-процесса. Можно только возложить ответственность за соответствие процедуры, требованиям организации на технолога-разработчика этой процедуры. Поскольку процедура применяется в организации многократно и различными должностными лицами, то операции бизнес-процесса могут быть атрибутированы только в виде ролей. Например: Инициатор, Нормоконтролер, Согласующий и т.д., кроме того за результат работы по данной процедуре в каждом случае может отвечать разное должностное лицо.

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

Основными характерными чертами процессов-процедур являются следующие:
• предназначены для документирования универсальных технологий, которые применяются в организации многократно и в различных целях;
• существуют в организации в виде нескольких экземпляров одной процедуры при этом каждый экземпляр имеет своего владельца процесса;
• процедура имеет одного владельца, который несет ответственность за ее актуальность и соответствие всем внешним и внутренним нормативным документам;
• также, как и в процессах-технологиях виды деятельности (операции) составляющие процедуры должны соответствовать функциям в должностных инструкциях сотрудников, но, в основном, на ролевой основе;
• предъявляют повышенные требования к тщательности проработки, из-за того, что используются как универсальные процедуры в виде нескольких экземпляров.

4. Исполняемые процессы. Эти процессы описываются в организациях чаще всего, так как они являются основой работы всех, без исключения, средств автоматизации. В первую очередь эти процессы встречаются в автоматизированных системах учета, планирования, документооборота и т.д. Как правило, в этих процессах описано взаимодействие человека и компьютера (информационной системы).

Примером таких процессов могут являться процессы бухгалтерского учета (автор надеется, что сегодня процессы бухучета автоматизированы с помощью того или иного программного обеспечения, практически во всех организациях) «Учет движения товарно-материальных ценностей (ТМЦ)», «Начисление заработной платы» и т.д. Хотя при их выполнении может участвовать только один сотрудник и один компьютер, тем не менее они имеют полное право называться процессами, так как обладают всеми присущими процессам свойствами. Вместе с тем исполняемые процессы, как правило, становятся заметны только тогда, когда заходит речь об их автоматизации. Вся деятельность систем документооборота, ERP, CRM и др. состоит из исполняемых процессов. Их настройка представляет собой существенный объем из всех трудозатрат по внедрению этих программных продуктов.

Основными характерными чертами исполняемых процессов являются следующие:
• документируются для последующей автоматизации и переноса в исполняемый вид для встроенных систем workflow;
• к документированию предъявляются повышенные требования в части подробности атрибутирования объектов, действий и адресации;
• могут не иметь прямо назначенного владельца процесса, но обязаны иметь ответственного за правильность работы по данной цепочке работ;
• в разных информационных системах могут действовать разные, взаимодействующие или повторяющиеся процессы;
• часто требуют интеграционных решений и/или импорта/экспорта данных из одной информационной системы в другую.
Таким образом в организации можно выделить четыре вида объектов, которые можно называть бизнес-процессами. Каждый вид объектов имеет свои особенности и предъявляет свои требования к моделированию, автоматизации и управлению.

1. Бизнес-процессы управления, - описывают управление крупными бизнес-объектами с помощью вертикальных информационных потоков и необходимы для поддержания системы управления (планирование, отчетность и аналитика для поддержки принятия управленческих решений).
2. Бизнес-процессы – технологии, - описывают уникальные технологические цепочки, в которых работают конкретные участники и, иногда могут быть автоматизированы с помощью цепочек workflow или docflow.
3. Бизнес-процессы – процедуры, - по ролевой модели описывают повторяющиеся в различных местах однотипные экземпляры одной процедуры. Этот вид процессов также иногда можно автоматизировать.
4. Исполняемые бизнес-процессы – бизнес-процессы самого нижнего уровня автоматизации, используемые для реализации функционала продуктов класса ERP или Документооборота. Подлежат описанию и автоматизации на 100% и являются самыми трудоемкими для автоматизации. Именно автоматизация их переноса из графического вида, понятного сотрудникам и бизнес-аналитикам, в исполняемый вид (BPMN, XPDL), который понятен программистам-имплементаторам, является наиболее трудоемкой частью любого IT-проекта.

Список литературы
1. Джестон Д., Нелис Й. Управление бизнес-процессами. Практическое руководство по успешной реализации проектов, Пер с англ.С-Пб, Символ-Плюс, 2008
2. Гради Буч Объектно-ориентированный анализ и проектирование с примерами приложений, 3 издание, : Пер с англ. М. : ООО «И.Д. Вильямс», 2008 г.

Комментарии

Оценки: 1/
10.03.2011 10:09
  от автора
  Богиня
Уважаемый Владимир!
• Те кто занимался бюджетированием,закупом и заключением договоров сами поняли наверное, что требования к этим бизнес-процессам у всех разные.
• На рисунке очень наглядно показано, кому, что нужно…..При подготовке презентаций отдельно для каждой группы потребителей информации, можно использовать пункты из – Что нужно?
Давно назревал вопрос об определениях, так как периодически в терминологии коллег мелькают то подпроцесс, то функция,начинаешь разбираться…а это оказывается одно и тоже имелось ввиду. В энциклопедии на портале не нашла формулировку,что такое подпроцесс, но зато есть функция –это совокупность однородных операций (в т.ч. – разных процессов), выполняемых структурным подразделением на постоянной основе.
Относительно статьи, интересно конечно, но появление новых терминов иногда вводит в заблуждение, вот например появились новые термины – подсистема,процесс-процедура,технологический процесс….., да и формулировка термина бизнес-процесс –отличается от прежней терминологии, где, бизнес-процесс – это устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для клиента. Терзают сомнения, если кто-то начнёт вводить дополнительные термины,или понятия,то будет путаница.
Оценки: /
10.03.2011 10:35
  от автора
  Репин
Богиня, просьба обратить внимание, что автор статьи - Виталий Елиферов. Вопросы нужно адресовать ему
Оценки: /
10.03.2011 10:46
  от автора
  Богиня
Сорри! я обратилась к автору разместившему статью,что-то как-то не заострила внимание на том,что статья В.Елиферова.
Оценки: /
10.03.2011 11:39
  от автора
  Елиферов Виталий
Давно назревал вопрос об определениях, так как периодически в терминологии коллег мелькают то подпроцесс, то функция,начинаешь разбираться…а это оказывается одно и тоже имелось ввиду

1. Именно поэтому и написана эта статья, поскольку в терминах существует путаница: "Это процесс или не процесс?" "Это бизнес-процесс или просто процесс?" "Почему нельзя для всех бизнес-процессов использовать BPMN?" и т.д.
2. А вот по поводу "... устойчивая ... деятельность..." - современные условия обработки информации и скорости принятия решений требуют минимальных временных затрат на перепроектирование процессов (бизнес-процессов). В бизнесе преуспевает тот, кто опережает изменения рынка, банально, но факт. Поэтому "устойчивость" процессов осталась в прошлом. Нужно иметь возможность быстро их менять. Об этом же пишет и Анатолий Белайчук в своем блоге http://mainthing.ru/ru/ , с провокационным позаголовком: Главное не результат, главное процесс!
Придется и мне спровоцировать затихшее болото специалистов: "Главное в процессе - это иерархия!"
. Почему? Об этом будет другая статья....
3. Мне ближе определение процесса из ИСО 9000:2005 "Процесс - совокупность видов деятельности преобразовывающая входы в выходы". Под это определение попадает и "Проект = уникальный процесс". Это определение включает и деятельность и затраты на руководителя - владельца процесса.
4. Недавно на этом портале в ходе обсуждения статьи, один участник договорился до фразы (почти буквальная цитата): "Обработка заявки в коммерческой организации - это бизнес-процесс, а в госоргане - не бизнес-процесс"
С уважением Виталий.
Оценки: /
10.03.2011 12:04
  от автора
  Репин
Привет, Виталий!

Да, некоторое "затишье". Вероятно, мужики отходят от 8 марта

"...технология, по которой работают процессы управления является слабо формализуемой и не поддающейся алгоритмизации, то есть автоматизировать можно только рутинные операции обмена информации и контроля за выполнением планов и поручений..."

Согласен про "рутинные" операции. Но на среднем и нижнем уровне менеджмента таких процессов будет 70-80%. На мой взгляд, процессы управления можно и нужно "технологизировать", а потом и автоматизировать. В качестве примера привожу структуру процессов управления, которые выполняет Начальник транспортного отдела некоторой реальной торговой компании:

1. Годовой контур управления
1.1. Планирование потребности в а/транспорте ( на основе расчета объема и веса и проч.)
1.2. Формирование графика ремонтов и ТО а/транспорта
1.3. Формирование бюджета ТО на год
1.4. Формирование графика отпусков сотрудников
1.5. Формирование отчета и анализ деятельности ТО за год
2. Квартальный контур управления
2.1. Корректировка потребности в а/транспорте
2.2. Заключение дополнительных договоров на услуги
2.3. Приобретение/замена автомобилей
2.4. Корректировка системы оплаты водителей и экспедиторов
2.5. Анализ, разработка предложений и корректировка графиков доставки по дистрибуции
2.6. Формирование отчета и анализ деятельности ТО за квартал
3. Ежемесячный контур управления
3.1. Корректировка потребности в а/транспорте
3.2. Анализ работы водителей и экспедиторов за месяц
3.3. Закрытие табелей по сотрудникам ТО
3.4. Формирование отчета и анализ деятельности ТО за месяц
3.5. Анализ, разработка/корректировка графиков доставки
4. Еженедельный контур управления
4.1. Контроль состояния автотранспорта
4.2. Планирование доставок внешних
4.3. Анализ деятельности ТО за неделю
5. Ежедневный контур управления
5.1. Анализ доставок за предыдущий день
5.2. Планирование доставок внутренних
5.3. Анализ отчетов диспетчеров, контроль дисциплины
5.4. Учет и контроль пробега автомобилей
5.5. Учёт и контроль норм выработки
Оценки: /
10.03.2011 12:21
  от автора
  NGont
"Регулярно и достаточно давно, занимаясь моделированием, описанием и реинжинирингом бизнес-процессов, а также управленческим консалтингом по реструктуризации предприятий и разработкой и внедрением систем менеджмента качества, автор обратил внимание на тот интересный факт, что при наличии большого количества литературы, посвященной проблемам процессного подхода и бизнес-процессам, в этой литературе не дается четких определений: Что такое бизнес-процесс и чем он отличатся от процесса?"
На моем столе лежат Ваши книги "Процессный подход к управлению" и "Бизнес-процессы:регламентация и управление", смотрим глоссарий:
Бизнес-процесс - устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности (последовательность работ), которая по определенной технологии преобразует входы в выходы, представляющие ценость для потребителя.
Процесс - см. бизнес-процесс.

Так в чем различие?
Оценки: /
10.03.2011 12:22
  от автора
  Богиня

Придется и мне спровоцировать затихшее болото специалистов: "Главное в процессе - это иерархия!"
. Уважаемый Виталий! Это Вы,что имеете ввиду, зависимость процессов от бп управления, основных, вспомогательных до единичных функций
Оценки: /
10.03.2011 13:12
  от автора
  Елиферов Виталий
Репину:
1. Не верю, что начальник транспортного отдела ЛИЧНО ведет учет и обработку путевых листов (5.4 и 5.5). Все остальные операции рутинны для небольшой компании, кроме "Закупка/замена автомобилей" - он инициирует потребность и выделение бюджета, а потом может и закупать по рутинной процедуре.
2. Судя по набору "процессов управления" - это небольшой начальник, небольшой компании (ЛИЧНО формирует отчеты 1.5, 2.6 3.4 да еще и ЛИЧНО и ЕЖЕНЕДЕЛЬНО "контролирует состояние автотранспорта" (4.1) и закрывает табель 3.3. Все эти действия не требуют особых менеджерских навыков.
3. Так что его деятельность вполне рутинна и управлением ее вряд ли можно назвать. Принятие решений о перераспределении ресурсов есть только в 1 и 2 разделах. В них и возникают проблемы при алгоритмизации принятия решений. В нижних процессах - легко автоматизируемая рутина.
С уважением Виталий.
P.S. В качестве экзотики: мне встречались Положения о подразделениях в которых были зафиксированы 33 задачи и 73 основные функции. Длинный список - это еще и неумение делегировать и организовывать работу подчиненных (у начальника транспортного цеха есть "руки" - диспетчера).
Оценки: /
10.03.2011 13:15
  от автора
  Елиферов Виталий

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

1. Различия нет, - это отражено в названии и эпиграфе.
2. + старею, умнею (иногда даже мудрею ) - серьезно: С временем и опытом, взгляды могут измениться...
Оценки: /
10.03.2011 13:24
  от автора
  Елиферов Виталий

Богине
Придется и мне спровоцировать затихшее болото специалистов: "Главное в процессе - это иерархия!"
. Уважаемый Виталий! Это Вы,что имеете ввиду, зависимость процессов от бп управления, основных, вспомогательных до единичных функций

В общем случае, - зависимость процессов от из расположения в иерархическом дереве структуры (не только оргструктуры организации).
Более подробно: - напишу позднее...
С уважением Виталий.
Оценки: /
10.03.2011 13:29
  от автора
  Репин
Виталию.
1. "...Не верю, что начальник транспортного отдела ЛИЧНО ведет учет и обработку путевых листов..."

В данной компании это так и было. Я спросил его, почему эту работу не может делать диспетчер. Он ответил, что "может, но мне так удобнее".

2. "..Судя по набору "процессов управления" - это небольшой начальник, небольшой компании (ЛИЧНО формирует отчеты 1.5, 2.6 3.4 да еще и ЛИЧНО и ЕЖЕНЕДЕЛЬНО "контролирует состояние автотранспорта" (4.1) и закрывает табель 3.3. Все эти действия не требуют особых менеджерских навыков.
3. Так что его деятельность вполне рутинна и управлением ее вряд ли можно назвать..."


Да, деятельность рутинная, как любая логистика. Не требует навыков? Не думаю, скорее наоборот - очень много нюансов по управлению парком и шоферами-экспедиторами. Но главное, что без такого управления процесс транспортировки просто не будет осуществляться эффективно! Начальник ТО отвечает перед ГД за эффективность использования парка, эффективность перевозки! Они меняют марки машин, меняют поставщиков услуг, меняют систему мотивации шоферов и т.п. Всё это - примеры ключевых управленческих решений, влияющих на эффективность! Как же можно утверждать, что "управления здесь нет"?
Оценки: /
10.03.2011 14:24
  от автора
  Елиферов Виталий
Владимир!
А почему моя фраза приведена не до конца?
Там еще были слова: "Принятие решений о перераспределении ресурсов есть только в 1 и 2 разделах. В них и возникают проблемы при алгоритмизации принятия решений. В нижних процессах - легко автоматизируемая рутина.
Управление есть в 1 и 2 разделах.
А то, что ему "удобнее", говорит или о том, что объемы учета (и соответственно перевозок) невелики, + об Управлении (раздел 1 и 2) он не думает (времени остается мало, все уходит на рутину).
С уважением Виталий.
Оценки: /
10.03.2011 14:35
  от автора
  Репин
"...А то, что ему "удобнее", говорит или о том, что объемы учета (и соответственно перевозок) невелики, + об Управлении (раздел 1 и 2) он не думает (времени остается мало, все уходит на рутину)..."

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

М.б. нам начать собирать на сайте коллекцию структур процессов управления для разных бизнесов? У меня в личной коллекции уже есть несколько примеров )
Оценки: /
10.03.2011 16:35
  от автора
  Елиферов Виталий

М.б. нам начать собирать на сайте коллекцию структур процессов управления для разных бизнесов? У меня в личной коллекции уже есть несколько примеров )

Процессов или функций?
1. Если функций: то модель APQC - вне конкуренции по списку общих, всеобщих и (местами избыточных) функций. Если дополнить ее еще и отраслевыми версиями (нефтегаз, аэрокосмическая, фармацевтика и т.д.) - список будет более чем достаточеный.
2. Если процессов: то референтная модель ИСО 9001:2000/2008 + (9004:2009) - тоже вне конкуренции. Более полные модели приобретают отраслевые признаки (см. п. 1).
3. Если отраслевые модели бизнеса: то лучше всех проработана модель еТОМ (+ OSS/BSS + NGOSS + SID).
Что коллекционировать будем?
С уважением Виталий.
Оценки: /
10.03.2011 18:38
  от автора
  Репин
Из указанных моделей к реальному бизнесу ближе eTOM. Но он подходит для весьма узкой линейки бизнесов.
Что касается процессов управления, то они отсутствуют как в APQC, так и в ИСО.
Можно начать создавать подборку систем процессов из различных отраслей, включая соответствующие процессы управления. Если участники сообщества поддержат идею, то можно создать под эту задачу отдельную группу.
В группе "Бизнес-процессы ритэйла" пока активности нет, к сожалению.
Оценки: /
11.03.2011 06:33
  от автора
  Богиня
Уважаемый Виталий! Вас во всей этой дискуссии представила в виде мушкетёра с саблей , всех раскидали по углам,один В.Репин ещё пытается как то держать оборону и пойти на компромисс. А теперь,если говорить о моделях,прочитала про все эти модели, что они представляют из себя,пришла к выводу,что модель еТОМ идеальный выбор, он дает возможность интегрировать между собой многие бизнес-процессы на нескольких предприятиях, являющихся поставщиками-партнерами друг друга или объединенных другими связями,что для нашей компании например,сейчас очень важно.Идея,Владимира интересная, надеюсь её поддержат участники сообщества! А какие будут стоять задачи у группы?
Оценки: /
11.03.2011 08:20
  от автора
  Богиня
Топ-менеджеры, включая генерального директора нуждаются в крупномасштабном видении бизнеса (деятельности) всей организации в целом. Это видение должно включать в себя информацию о структуре целей всей организации, о том, какие цели могут быть соотнесены с какими процессами и руководителями, о том, как выстроена система планирования и отчетности.

Автоматизация деятельности топ-менеджеров должна включать оперативное предоставление всей необходимой информации и аналитики для принятия управленческих решений, а также систему документооборота и контроля за исполнением планов, решений и поручений»


Прочитала ещё раз статью. И представилась мне сказка,которая может наверное стать былью ( во всяком случае у нас)
В компании всё автоматизировано,до единичного функционала. Генеральный директор может уже и не приходить на работу..С утра выспавшись, он заглядывает в монитор своего компа и… заходит «на предприятие».
Видит с утра все отделы работают, у всех всё хорошо, горят зелёные лампочки ( признак того,что всё по процессу). Он уходит поплавать в бассейне,на тренажёры..,снова приходит и видит уже другую картинку, в одном из отделов горит жёлтая лампочка, он нажимает туда и видит картинку-процесса отдела, а также видит в каком месте проблема. Он уверен, что проблема решится на операционном уровне. Идёт завтракать. Возвращаясь…он видит другую картинку – там,где была жёлтая лампочка, уже красная, но ещё в двух подразделениях горят жёлтые лампочки. Он нажимает на красную лампочку и видит, что владелец процесса отдела, как оказалось не принял своевременных действий по устранению проблемы ,генеральный даёт ему ЦУ, на что сразу,же будут предприняты меры по устранению сложившейся ситуации ( владелец,новенький !) Генеральный, занятый решением более глобальных проблем(покупка акций, вложение инвестиций в прибыльные отрасли бизнеса ,всевозможные деловые поездки и встречи), периодически заходит «на предприятие»,чтобы посмотреть ситуацию. Нажав на любую «лампочку-подразделение», по гиперссылке может проверить состояние дел за день, неделю, месяц. Может получить отчёт о доходной и расходной частях предприятия, информацию о полученной прибыли. Т.е. генеральному директору совсем неважны процессы внутри компании, операционки, он видит свой бизнес сверху, его задачи совсем другие……Кстати, он может создать несколько таких предприятий Вобщем…просто сказка!
Это я к чему?! Это я к тому,что, уважаемые Владимир и Виталий, авторы многичисленных ,очень полезных книг – Ваше дело правое! Поиск способов уявзать БП, оптимизировать,автоматизировать..…для достижения максимальной эффективности предприятия.И только в споре рождается истина!
Оценки: /
11.03.2011 09:53
  от автора
  Репин
Привет, Богиня!
Спасибо! Кстати, при внедрении систем класса Business Performance Management у руководителей действительно появляются "светофоры", панели управления с дрилл-даун и т.п. Вопрос только в том, кто сможет адекватно описать бизнес-процессы и подобрать для них показатели (метрики), которые с минимальным риском будут давать собственнику и топ-менеджеру полную, многогранную картину бизнеса. Тогда можно будет и в бассейн, и в солярий, и в ресторан...

Примеры панелей:







В проектах мы как описываем процессы, так и подбираем показатели для управления.

Насчет коллекции систем процессов - ждем реакции сообщества
Оценки: /
11.03.2011 10:22
  от автора
  Богиня
Вопрос только в том, кто сможет адекватно описать бизнес-процессы и подобрать для них показатели (метрики), которые с минимальным риском будут давать собственнику и топ-менеджеру полную, многогранную картину бизнеса. У меня сложилась ситуация, процессы описаны, но показатели,по которым необходимо их оценить оказались не те,что я ранее предполагала.Теперь получается надо будет и процесс пересмотреть и показатели будут уже другие, а "поезд-то уже в пути". Т.е.границы процессов очерчены,спецификации входов-выходов подписаны,владельцы назначены.....
Оценки: /1
11.03.2011 10:32
  от автора
  Репин
Границы можно и нужно периодически пересматривать. Владельцев можно переназначать.

Маленький анекдот из жизни.

Приезжаю консультировать предприятие в регионе. Спрашиваю: "У вас процессный подход на внедрен?". Отвечают - "Внедрен... Три года назад". Выяснилось, что три года назад они описали процессы (пример довольно поверхностно) и аккуратно хранили схемы процессов в шкафу...
Оценки: /
11.03.2011 11:03
  от автора
  Елиферов Виталий
Богиня!
Вас во всей этой дискуссии представила в виде мушкетёра с саблей , всех раскидали по углам,один В.Репин ещё пытается как то держать оборону и пойти на компромисс.

1. Мушкетеры пользовались не саблями, а шпагами. Шпагу я в руках не держал, только фехтовальную рапиру, да и то более 30 лет назад.
2. Репин? В обороне? - смеетесь Вы над нами. Мы слишком давно знаем друг друга (10 лет), чтобы обороняться.
3. Модель еТОМ применима во многих отраслях, но ее нужно модифицировать. Например, однажды эту модель удалось прмменить для водоканала (какая разница, что течет по трубам-проводам).
4. Вы не поверите, но
И представилась мне сказка,которая может наверное стать былью ( во всяком случае у нас)
В компании всё автоматизировано,до единичного функционала. Генеральный директор может уже и не приходить на работу..С утра выспавшись, он заглядывает в монитор своего компа и… заходит «на предприятие».

...эту быль я уже видел реализованной не один раз. Сам 3 года назад проектировал панель BI для гендира крупной компании, с возможностью drill-down (но это потребовало: изменения оргструктуры и функционала подразделений, изменения всей учетной политики, изменения всей системы управленческого учета). А сейчас получение этой информации на iPad - проблемы не составляет. Так работают топы в секторе телекомов.
5. По поводу проблем с изменением выделенных процессов при появлении системы показателей, придется сказать, значит Вы учли не все факторы при выделении процессов. Как правило, топ-менеджменту требуются не просто показатели, а система отчетности по объектам управления. Значит в данном проекте процессы были выделены по признаку технологии, а не по признаку потребностей управлять объектами. Каким образом владельцы "подписывали спецификации", если в них не было системы отчетности (или она не совпадала с потребностями руководства)?
6. Ответ на Ваш вопрос: "Адекватно описать бизнес-процессы и подобрать показатели(метрики)" сможет только высоквалифицированный и опытный консультант, понимающий: как это надо делать.
С уважением Виталий.
P.S. Cлегка, и рапирой...
Оценки: /
11.03.2011 11:10
  от автора
  NGont


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


Отвечают - "Внедрен... Три года назад". Выяснилось, что три года назад они описали процессы (пример довольно поверхностно) и аккуратно хранили схемы процессов в шкафу...

quote


А самая прелесть состоит в том, что пока "и в бассейн, и в солярий, и в ресторан..." ничего нельзя менять. Сказка!
Оценки: /
11.03.2011 12:00
  от автора
  Богиня
Виталию Елиферову
Ну всё....укол...шпагой, ой,т.е.саблей, вобщем рапирой
Оценки: /
11.03.2011 12:19
  от автора
  Елиферов Виталий
Богине
Ну всё....укол...шпагой, ой,т.е.саблей, вобщем рапирой

Не получится укол. Сегодня в боях используются только электрорапиры с плоским подпружиненным наконечником в виде шляпки, вдоль клинка желобок в котором проходит провод, подключеный к контактам на эфесе. Укол считается, если пружина наконечника сжалась и замкнула конатакт (усилие больше 50 г., так кажется) при соприкосновении с электрожилетом противника.
Острое оружие - запрещено.
Оценки: /
11.03.2011 12:35
  от автора
  Богиня
Виталию Елиферову:Не получится укол.Острое оружие - запрещено.Острое оружие - запрещено. Ну,спасибо...а то меня уж сомнения терзать стали,всяки-разные..."Адекватно описать бизнес-процессы и подобрать показатели(метрики)" сможет только высоквалифицированный и опытный консультант, понимающий: как это надо делать. таааак,похоже нам в будущем консультат потребуется, а мы тут шашаками махаемся.
Оценки: /
11.03.2011 14:07
  от автора
  Елиферов Виталий
таааак,похоже нам в будущем консультат потребуется, а мы тут шашаками махаемся.

Я не махаюсь, - я консультирую..
Оценки: /
11.03.2011 17:04
  от автора
  Рафик Ямолеев
Проспал все интересное - тоже всппомнился анекдот, когда сторожу предложили высокооплачиваемую работу - сортировать яблоки: гнилые - в мусор, те, что побольше, - в одну корзину, что поменьше - в другую, а он через неделю он взмолился о переводе обратно: "Это ж каждую секунду нужно принимать решения!"

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

Предлагаемая Виталием Геннадьевичем классификация, конечно же, заслуживает осмысления.

А 1. Процессы управления сразу же очень хочется переименовать в Процессы принятия решений

P.S. Очень хотелось бы познакомиться с отзывами коллег об универсальном контуре регулирования, который я встретил в монографии С.В.Рубцова. На мой взгляд, этот конструкт сильно перекликается с циклом PDCA. И его я при моделировании использую чаще. И термином "бизнес-процесс", как уже писал, пользуюсь крайне редко.
Оценки: /
11.03.2011 17:54
  от автора
  Елиферов Виталий
Предлагаемая Виталием Геннадьевичем классификация, конечно же, заслуживает осмысления.
А 1. Процессы управления сразу же очень хочется переименовать в Процессы принятия решений
P.S. Очень хотелось бы познакомиться с отзывами коллег об универсальном контуре регулирования, который я встретил в монографии С.В.Рубцова. На мой взгляд, этот конструкт сильно перекликается с циклом PDCA. И его я при моделировании использую чаще. И термином "бизнес-процесс", как уже писал, пользуюсь крайне редко.

Спасибо, Рафик!
1. "Принятие решения" - узко для управления. На мой взгляд, процесс управления включает в себя, как минимум 3 основных части из PDCA - P*CA - то есть: С - check - сбор информации (иногда и анализ)
А - Act - Анализ информации и принятие решения
Р - Plan - Доведение решения до исполнителей (Do).
С уважением Виталий.

Оценки: /
11.03.2011 18:59
  от автора
  Репин
Отцы, скиньте ссылку на книгу С.Рубцова - не встречал...
Оценки: /
11.03.2011 19:56
  от автора
  Рафик Ямолеев
Владимир, встречал только у него на сайте.

Контур саморегулирования здесь

Виталий Геннадьевич, только "принятие" - наверное узко. Поленился набрать - процессы формирования альтернатив и осуществления выбора между ними по какому-либо критерию.

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

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

С уважением Рафик
Оценки: /
11.03.2011 23:30
  от автора
  Елиферов Виталий
Рафик:
Геннадьевич, только "принятие" - наверное узко. Поленился набрать - процессы формирования альтернатив и осуществления выбора между ними по какому-либо критерию.

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

Даже в случае удаленного сбора информации на точке без присутствия человека?
Примеры: Фотоизмеритель скорости автомобиля, каротажные датчики в нефтяной скважине, датчики в активной зоне реактора, радиотелескоп "Хаббл"
Анализ должен производиться там и тогда, где это максимально удобно и выгодно.
С уважением Виталий.
P.S. Предлагаю альтернативу: или Вы сообщаете свое отчество (В И-нете найти не смог), или переходим на имена. Второе предпочтительнее.
Оценки: /
12.03.2011 09:21
  от автора
  Рафик Ямолеев
P.S. Предлагаю альтернативу: или Вы сообщаете свое отчество (В И-нете найти не смог), или переходим на имена. Второе предпочтительнее
Шутку понял. Смешно.
Переходим на имена, Виталий.
Прошу простить за ошибку в написании Вашего отчества - память подвела.

А не хотите вставить: - анализ сформированных альтернатив - выбор между ними -
Наверное, и это будет правильнее.

Под "анализом" подразумевал несколько более широкое явление, нежели некую выделенную область деятельности человека. Вкратце, в примерах, приводимых Вами, в моем представлении анализ присутствовал на стадии проектирования упоминаемых приборов, при рассмотрении требований к ним - что должен уметь прибор? Грубо: вот это - нужно, это - не нужно, фильтруем и тд.

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

Тема важная и интересная. С разгону писать не получается. Надо обдумывать.

P.S. Кстати, зацепила мысль, высказанная Загидуллиным Р.Р. в своей статье "Как управлять процессами машиностроительного предприятия"

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

При этом анализу подлежит жизненный цикл заказа. Отслеживается весь путь, который проходит заказ, от заявки со стороны заказчика, до отгрузки готовой продукции и на каждом этапе для каждого подразделения, через которое проходит заказ, определяется состав БП, связанный именно с этим заказом. Проанализировав все входящие заявки, можно определить состав и мощность всего множества БП.

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


Учитывая предложение Владимира
М.б. нам начать собирать на сайте коллекцию структур процессов управления для разных бизнесов? У меня в личной коллекции уже есть несколько примеров
все одно к одному.
Оценки: /
12.03.2011 09:26
  от автора
  Рафик Ямолеев
Анализ должен производиться там и тогда, где это максимально удобно и выгодно.
Например, на стадию проектирования - анализ того, что может и должен давать "автоматический" анализ.
Оценки: /
12.03.2011 17:30
  от автора
  Елиферов Виталий
Ямолееву:
Сожалею, Рафик, но я не поддерживаю взгляды Загидуллина в том, что IDEF, UML или ERP - являются инструментарием для процесса управления бизнес-процессами.
Выбор инструментария для процесса управления БП достаточно широк – от отдельных программных оболочек, поддерживающих либо нотации IDEF, либо универсальный язык UML (Unified Modeling Language), до соответствующих модулей ERP-систем (Enterprise resource planning).

На мой взгляд эти продукты не имеют никакого отношения к управлению в контексте "менеджмент" (планирование, организация, контроль, координация, мотивация). Мне ближе взгляды Файоля, Деминга, Друкера, Янга, Оптнера и т.д. А если и имеют, то не больше чем "стол, кресло и секретарша директора" То есть, менеджментом организации эти продукты не занимаются.

Тезис:
По сути дела большинство БП возникает как следствие необходимости выполнения ТП, т.е. выполнение большинства БП можно отнести к комплектации ТП.

- тоже является спорным, хотя спор и напоминает проблему "что раньше курица или яйцо". Все же в любом бизнесе (сключая машиностроение), то, что Равиль называет бизнес-процессами, определяет набор ТП, а не наоборот. Маркетинг и коммерсанты задают вектор изменения технологических процессов любой организации.
С уважением Виталий.
P.S. Все равно мое отчество правильно не напишете, я живу с ошибкой в паспорте.
Оценки: /
12.03.2011 20:33
  от автора
  Рафик Ямолеев
А я, похоже, не обратил внимания на предложения об инструментарии. Видимо машинально отнес моделирование к планированию, организации и контролю. Т.е. можно и без них, но с ними (CASE-инструментами) определенную "часть" управления организацией осуществлять стало в некотором смысле легче.

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

Мне показалась интересной именно задача составления полного (универсального?) перечня БП. Вполне возможно, что нечто я и домыслил.

P.S. Думаю, в паспорте - ошибок быть не может.
Оценки: /
13.03.2011 19:27
  от автора
  Елиферов Виталий
1. Я давно знаком с Загидуллиным и его работами (даже есть его книжка с дарственной надписью ). Область его интересов, - технологические процессы (по моей классификации), точнее - первичные, атомарные процессы, из которых состоят технологические процессы. Алгоритмизация составления расписаний для цеховой MES-системы с учетом доступности ресурсов (процессоров), последовательности или параллельности работ (операций) атомарные ветвления и расчеты на основе сетей Петри.
http://www.ugatu.ac.ru/science/dissov/d3/16.03/zagidullin_r_r.pdf
2.
Составление полного (унивесального) перечня БП

... задача, на мой взгляд утопичная.
Вы не обращали внимание, как написаны книги по менеджменту?
А) перечисление банальных правил: Миссия, Цели, Маркетинг, Показатели, Организация работ, Бюджетирование, Экономия, Качество, "Облизывание клиента до его полного удовлетворения".
Б) В компании "ААА" дела шли плохо, но потом они сделали "ZZZ". и у них все стало хорошо. А Вот в компании "БББ", когда дела пошли плохо, они сделали "YYY" - и стали миллионерами, тем не менее, компании "ВВВ" не помогло ни "ZZZ", ни "YYY" - зато они сделали "XXX" - и разорились.
То есть, есть 2 вида книг: Сухие конструкции или Многочисленные примеры (которые сработали когда-то и где-то).
Также и с бизнес-процессами, побеждает тот, кто выстроит их наиболее оптимально здесь и сейчас, в этой конкретной компании и условиях. Копилка может пригодиться лишь для обучения. Но большинство консультантов, которые не могут сами отстроить бизнес, берут такие копилки и пытаются втиснуть в них живую жизнь.
Не зря мы с Володей писали в первой книге (Процессный подход к управлению ...2004 г.), что модель APQC - избыточна, это только справочник, на который нужно смотреть, но не копировать.
С уважением Виталий.
P.S. В отношении правил русского языка ошибки могут быть и в паспорте.
Оценки: /
14.03.2011 16:08
  от автора
  Рафик Ямолеев
1.1. Виталий, спасибо за ссылку на автореферат.
1.2. Книг Загидуллина нет. Есть книги Репина и Елиферова без надписей. С Владимиром как-то не пересеклись, но он сказал, что подпишет без проблем. И у Вас сейчас попытаюсь добро получить.
Кстати, первое издание вашей с Владимиром книги "Процессный подход к управлению ...2004 г." покупал прямо в издательстве на Дубровке. Был вторым.

2. По поводу полного (универсального) перечня процессов постараюсь представить свое видение подробнее чуть позже. Самому надо ухватить, а затем офрмить идею, которая тогда промелькнула в голове вслед за текстами ЕСТД и ЕСПП.

P.S. Написанное в паспорте заруливает правила любого языка в глубокие минуса.
Оценки: /
14.03.2011 16:14
  от автора
  Елиферов Виталий
Есть книги Репина и Елиферова без надписей. С Владимиром как-то не пересеклись, но он сказал, что подпишет без проблем. И у Вас сейчас попытаюсь добро получить.
Кстати, первое издание вашей с Владимиром книги "Процессный подход к управлению ...2004 г." покупал прямо в издательстве на Дубровке. Был вторым.

С моей подписью тоже проблем нет.
Чуть-чуть развлеку Вас, первая наша книга была написана осенью 2002 г., и 1,5 года блуждала по издательству, вышла весной 2004 г. Тем временем мы написали вторую и она вышла осенью того же 2004 г. Вот как было забавно.
С уважением Виталий.
Оценки: /
14.03.2011 17:20
  от автора
  Рафик Ямолеев
Бывает, да.
Вторая тоже у меня есть. И обе третьи.

Если память не подводит, я тогда подумал что-то навроде "вот производительность у людей в деле написания книг!".

Почитаю автореферат, может я не так понял написанное Равилем Рустэм-бековичем по поводу перечня ТП.
С уважением Рафик
Оценки: /
14.03.2011 17:52
  от автора
  Елиферов Виталий
Если память не подводит, я тогда подумал что-то навроде "вот производительность у людей в деле написания книг!".

Это не наша производительность, - это их медлительность. Для нас 2 года, вдвоем на 2-ю книгу - нормальный темп.
С уважением Виталий.
Оценки: /
31.03.2011 19:02
  от автора
  xtlan
Прочёл статью не по факту появления на сайте, а после получения рассылки, поэтому несколько позднее включаюсь в обсуждение, а жаль, что не по горячим следам.

1. "...объекты управления в организации выделяют и описывают не профессиональные менеджеры, а IT-специалисты, просто потому, что они лучше знают «птичьи языки» моделирования и программирования".

В данном тезисе вижу подразумеваемое автором как верное утверждение, что профессиональные менеджеры в состоянии описать объекты управления и процессы (о которых в цитате речи не идёт, но которые появляются далее).

К сожалению, не довелось встретить ни самому, ни выявить через коллег профессиональных менеджеров, способных не то что описать, а даже сообщить о том, какими же объектами они управляют (одно из оригинальных определений, что объектами управления на предприятии "являются формы капитала" - и много ли менеджеров способны определить подобное? (без комментариев)).

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

Сами процессы в организации очень сложны (достаточно сослаться на модели борьбы со сложность в книге "Мозг фирмы" С.Бира), что же удивляться, что менеджеры не могут да и не должны знать всех деталей выполнения процесса? Потому и не способны описывать и моделировать, да и не их это задача, на мой взгляд. Они должны формулировать цели и ставить задачи, как достичь такие цели, а также контролировать ход достижения целей, принимая решения в ходе движения к целям. А вот моделирование процессов лучше отдавать профессионалам.

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

2. «Организации нужна не модель бизнес-процессов, а повышение эффективности работы и управления». Полностью согласен с автором в данном тезисе, не вижу здесь никакой крамолы. Само описание процессов служит инструментом в достижении цели - "повышение эффективности работ и управления". Другой вопрос - а когда это нужно? Видимо, когда организация испытывает кризис, связанный с эффективностью и управлением. А в других случаях описания процессов ей ни к чему.

3. "При этом необходимо помнить, что под процессом (бизнес-процессом) мы понимаем, совокупность видов деятельности или объекты, которые целесообразно выделять и документировать в организации для основной деятельности и управления."

Всё-таки непонятно: бизнес-процессы - это совокупность видов деятельности или объекты? Вроде совершенно разные сущности, а мы их - отождествляем под определением "бизнес-процесс". Странно, как объект может быть процессом...
Оценки: /
31.03.2011 22:45
  от автора
  Репин
"...Плоды же трудов "профессиональных менеджеров", которые можно было бы отнести к описаниям процессов, годятся разве что для того, чтобы "поговорить на эту тему" - попробуйте поработать в соответствии с этими "описаниями", и вся их неприменимость к реальной жизни ... станут очевидны. Потому-то и выходит на первый план роль ИТ-специалистов и грамотных бизнес-аналитиков..."

- во многом согласен.

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

Не согласен. На мой взгляд, кризисная ситуация - неустойчивая ситуация. Процессы очень быстро меняются. В этом случае их описание может оказаться бесполезным. Если имеется в виду застой, бюрократия, то описание процессов может помочь, согласен.
Если бизнес развивается стабильно, то процессный подход может сделать его более эффективным.
Оценки: /
01.04.2011 10:58
  от автора
  xtlan
"Другой вопрос - а когда это нужно? Видимо, когда организация испытывает кризис, связанный с эффективностью и управлением. А в других случаях описания процессов ей ни к чему..."

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

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

Если же организация ещё не нащупала свою рыночную нишу, то ей приходится менять виды своей деятельности, постоянно адаптироваться, функциональное управление делает её более гибким, процессы постоянно меняются - тогда ей и описания их не особо нужны, не дают они ожидаемого эффекта.
Оценки: /
01.04.2011 11:23
  от автора
  Репин
А чем отличается "функциональное" управление от "процессного"? Приведу несколько моментов:
Якобы "Функциональное" управление:
1. у руководителей нет времени, желания, компетенции структурировать процессы и закрепить их в стандартах работы - в итоге все работают "по понятиям";
2. бардак в работе, потери и т.п., покрываемые избыточным количеством ресурсов;
3. "герметизация" информации руководителями и специалистами, "замыкание" всех коммуникаций на себя, искусственное создание узких мест и т.п.;
4. репрессивный стиль менеджмента, при котором проблемы и недостатки срываются сотрудниками и т.п.

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

На мой взгляд, вообще некорректно противопоставлять "функциональное" и "процессное" управление. Процессы есть всегда. Только в одной ситуации они не прописаны, информация о требованиях к работе - в головах сотрудников, бардак в управлении. Во другой ситуации - есть стандарты на процессы, всё "прозрачно", управление эффективно.
Оценки: /
01.04.2011 15:36
  от автора
  xtlan
По п. 1-4 возражений нет, действительно - бардак в управлении. Но разве это не наиболее часто встречаемая ситуация?

Различие в функциональном и процессном управлении сформулировал бы следующим образом: разница в том, на чём сфокусирован менеджмент - в основном на усовершенствовании процессов внутри своих подразделений (функциональное), или в целом в организации, в том числе и на интерфейсах между подразделениями, то есть на кросс-функциональном уровне, с так называемой горизонтальной точки зрения (процессное).

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

То, что описание процессов добавляет прозрачности - спору нет. Как и в том, что подобные описания очень сложно поддерживать в актуальном состоянии, а уж контролировать исполнение процессов в соответствии с описаниями без автоматизации - ещё проблемнее.
Оценки: /
01.04.2011 22:28
  от автора
  Репин
"...подобные описания очень сложно поддерживать в актуальном состоянии, а уж контролировать исполнение процессов в соответствии с описаниями без автоматизации - ещё проблемнее..."

Конечно, если в компании из 1000 человек исполнение стандартов по бизнес-процессами контролируют только три бизнес-аналитика (которые эти стандарты и "рисуют"), то добиться их исполнения абсолютно не реально. Нужны механизмы контроля исполнения регламентов по бизнес-процессам, а именно:
1. самоконтроль исполнителями (чек-листы, журналы и т.п.);
2. контроль непосредственными руководителями (периодически + актуализация регламентов);
3. контроль при помощи внутреннего аудита;
4. контроль при помощи системы показателей;
5. контроль параметров процессов при помощи автоматизации.

Автоматизация процессов (BPM-системы, например) - это не панацея. Сушество очень много процессов, которые в BPMS не реализуешь, но управлять ими нужно. Кстати, некоторые сторонники BPNS как-бы не видят тех процессов, которые не могут быть автоматизированы. Их вроде как "не существует". Это, очевидно, удобная позиция с точки зрения маркетинга BPM-система. Но она не удобна для клиента.

Было бы интересно обсудить методы, позволяющие добиться создания в организации культуры работы по регламентам.
Оценки: /
02.04.2011 09:19
  от автора
  Елиферов Виталий
xtlal
"...Само описание процессов служит инструментом в достижении цели - "повышение эффективности работ и управления". Другой вопрос - а когда это нужно? Видимо, когда организация испытывает кризис, связанный с эффективностью и управлением. А в других случаях описания процессов ей ни к чему..."

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

А я бы согласился с XTLAN (ну и ник у Вас )
Володя, мы не раз с тобой встречали ситуации, когда естественным монополиям, госструктурам процессы были не нужны (если только в политических целях "у нас тоже есть").
Давайте все же разделять: кризис и развитие.
Для того, чтобы возникла потребность что-то поменять, кризис не обязателен, достаточно потребности организации в развитии (у монополий и госструктур ее нет). Чтобы развиваться, нужно менять себя. Как поменять работу организации, если она не документирована? Как поменять процесс, если в случае работы "по понятиям" каждый участник имеет о нем свое собственное представление? В какой объект управления будем вносить изменения и в какую часть, если она существует только в воображении?
Таким образом будет плодиться хаос, за которым наступит кризис.
С уважением Виталий.
Оценки: /
02.04.2011 10:10
  от автора
  Елиферов Виталий
xtlan
Всё-таки непонятно: бизнес-процессы - это совокупность видов деятельности или объекты? Вроде совершенно разные сущности, а мы их - отождествляем под определением "бизнес-процесс". Странно, как объект может быть процессом...

Ничего странного:
1. Не каждый "объект" может быть назван "процессом". Операция по наклеиванию марки на конверт с помощью языка, вряд ли может на это претендовать. Объекты модели процесса "продукт", "ресурс" - тоже процессом не назовешь.
2. Каждый процесс- это объект управления (взгляд извне).
3. Каждый "процесс - это совокупность действий по преобразованию...." (взгляд изнутри на содержимое "процесса". Эта совокупность и включает в себя объекты модели процесса "управление процессом", "ресурсы процессы", "технология процесса" и т.д.
С уважением Виталий.
Оценки: /
06.04.2011 10:47
  от автора
  xtlan
Владимиру Репину

"Автоматизация процессов (BPM-системы, например) - это не панацея. Сушество очень много процессов, которые в BPMS не реализуешь, но управлять ими нужно."

Согласен, что автоматизация не панацея - но она в состоянии существенно снизить нагрузку на контролирующие органы.

Могли бы Вы привести примеры процессов, которые в принципе нереализуемы в BPMS системах (разумеется, без привязки к конкретной системе, поскольку того, чего нет в одной, может быть в другой)? Не перекрывается ли данный пробел появлением в последнее время так называемых ACM систем?

"Кстати, некоторые сторонники BPNS как-бы не видят тех процессов, которые не могут быть автоматизированы. Их вроде как "не существует". Это, очевидно, удобная позиция с точки зрения маркетинга BPM-система. Но она не удобна для клиента."

Вполне допускаю подобный феномен. Как говорится, "если в ваших руках молоток, то все проблемы видятся гвоздями". Тот же вопрос: примеры подобных процессов можно привести? Любопытно...


"Было бы интересно обсудить методы, позволяющие добиться создания в организации культуры работы по регламентам."

Мне кажется, что подобные вещи вполне реализуемы при наличии нескольких моментов:

1. Наличие воли со стороны реально имеющих власть и ресурсы лиц на реализацию работы по регламентам;
2. Наличие инструментов для контроля за исполнением регламентов (тут вполне предпочтительно использование систем типа BPM, но и описанные Вами варианты вполне годятся);
3. Рассмотрение данного вопроса с точки зрения Human Performance Management. Ну и, конечно, учёт менталитета...
Оценки: /
06.04.2011 10:56
  от автора
  Елиферов Виталий
Можно, я отвечу?
Могли бы Вы привести примеры процессов, которые в принципе нереализуемы в BPMS системах (разумеется, без привязки к конкретной системе, поскольку того, чего нет в одной, может быть в другой)? Не перекрывается ли данный пробел появлением в последнее время так называемых ACM систем?

Примеры из области девелопмента:
1. Процессы получения разрешительной документации на а) перевод земель из одной категории в другую; б) получения разрешения на строительство; в) получения ТУ на подключение водоснабжения/водоотведения, эленергии и теплоснабжения.
Примеры из любой отрасли
2. Процессы претензинно-исковой работы, решения проблем в судебном порядке.
и т.д.
С уважением Виталий.
Оценки: /
06.04.2011 11:18
  от автора
  xtlan
Виталию Елиферову:

"Давайте все же разделять: кризис и развитие. Для того, чтобы возникла потребность что-то поменять, кризис не обязателен, достаточно потребности организации в развитии (у монополий и госструктур ее нет). Чтобы развиваться, нужно менять себя. "

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

"Как поменять работу организации, если она не документирована? Как поменять процесс, если в случае работы "по понятиям" каждый участник имеет о нем свое собственное представление? В какой объект управления будем вносить изменения и в какую часть, если она существует только в воображении?
Таким образом будет плодиться хаос, за которым наступит кризис."

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

Хаос плодится, когда потребности системы входят в противоречие с принципами управления ею (прямо марксизм-ленинизм - это и есть кризис.

"1. Не каждый "объект" может быть назван "процессом".".

Собственно, как раз в этом-то и был вопрос: исхожу из посылки, процесс не есть объект, а последовательность изменений состояний объекта во времени. Поэтому и возник вопрос...

"2. Каждый процесс- это объект управления (взгляд извне)"

Вот с этим никак не могу согласиться в силу указанных выше причин.

"3. Каждый "процесс - это совокупность действий по преобразованию...."

А вот это определение - с другой точки зрения. Когда рассматриваем, почему же объект меняет свои состояния во времени - оказывается, потому, что в отношении него мы применяем некоторые действия, которые способствуют изменению его состояний.



Оценки: /
06.04.2011 11:34
  от автора
  Репин
"...Могли бы Вы привести примеры процессов, которые в принципе нереализуемы в BPMS системах..."


Пожалуйста Их есть у меня:
- ведение телефонных переговоров менеджером по продажам (есть регламент выполнения звонка);
- проведение встречи с клиентом менеджером по продажам (есть регламент проведения переговоров);
- замена масла автослесарем на автомобиле;
- доставка книжек курьером (получение товара на складе, звонок клиенту, доставка, получение денег, оформление, сдача денег в кассу).

Коллеги, количество процессов, неавтоматизируемых в BPMS, многократно превышает количество эффективно автоматизируемых. Но неавтоматизированными процессами тоже нужно управлять!
Оценки: /
06.04.2011 12:03
  от автора
  xtlan
Виталию Елиферову:

Спасибо. В общем-то, именно об этих процессах и думал. Похоже, расширение BPM в сторону реализации ACM и призвано включить в себя данные возможности.
Оценки: /
06.04.2011 13:38
  от автора
  xtlan
"Пожалуйста Их есть у меня:
- ведение телефонных переговоров менеджером по продажам (есть регламент выполнения звонка);
- проведение встречи с клиентом менеджером по продажам (есть регламент проведения переговоров);
- замена масла автослесарем на автомобиле;
- доставка книжек курьером (получение товара на складе, звонок клиенту, доставка, получение денег, оформление, сдача денег в кассу)."

Владимир, в отношении приведённых примеров можно поспорить: если есть регламент - значит, есть алгоритм, а если есть алгоритм - автоматизируемо. Далее - вопрос юзабилити...

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

Рассмотрим замену масла автослесарем. Я бы задался следующими вопросами: "Чем хотим управлять в данном процессе? Что мы хотим автоматизировать? Последовательность действий автослесаря? С какими целями? Что хотим контролировать (Какое масло взял, слил ли сначала старое, а потом залил новое? Сделал ли промывку? Сделал ли согласно технологическим требованиям?)? Если автослесарь прошёл обучение, имеет рабочую инструкцию, регламент, но не выполняет по ним свою работу должным образом - а нужен ли нам сотрудник, неспособный к обучению?

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

Оценки: /
06.04.2011 14:10
  от автора
  Елиферов Виталий
"1. Не каждый "объект" может быть назван "процессом".".
Собственно, как раз в этом-то и был вопрос: исхожу из посылки, процесс не есть объект, а последовательность изменений состояний объекта во времени. Поэтому и возник вопрос...
"2. Каждый процесс- это объект управления (взгляд извне)"
Вот с этим никак не могу согласиться в силу указанных выше причин.
"3. Каждый "процесс - это совокупность действий по преобразованию...."
А вот это определение - с другой точки зрения. Когда рассматриваем, почему же объект меняет свои состояния во времени - оказывается, потому, что в отношении него мы применяем некоторые действия, которые способствуют изменению его состояний.

Если я правильно понял, с Вашей точки зрения Процесс - это технология преобразования входа в выходы.
Но... Технологию - кто-то разработал и несет ответственность за ее эффективность (управляет технологией). Технология - объект управления.
Процесс - кто-то исполняет и несет ответственность за исполнение технологии и очередности работ (по приоритетам) - управляет тоже, однако. Реализация процесса - объект управления.
Состояние ресурсов, входов, исполнителей в ходе процесса меняется (износ, старение, пенсионные отчисления) - ресурсами опять же надо управлять. Ресурсы процесса - объект управления.
То есть, с точки зрения математической модели, начальное состояние процесса описывает многомерное пространство состояний (параметров объектов модели), которое в ходе выполнения процесса должно перейти в целевое пространство состояний (пошагово, по орграфу или сетям Петри).
Статья на эту тему уже написана мною в соавторстве с одним математиком, скоро вылижем ее и где-нибудь напечатаем.
С уважением Виталий.


Оценки: /
06.04.2011 19:08
  от автора
  xtlan
"Если я правильно понял, с Вашей точки зрения Процесс - это технология преобразования входа в выходы. Но... Технологию - кто-то разработал и несет ответственность за ее эффективность (управляет технологией). Технология - объект управления."

Смотрю на процесс шире. Процесс для нас становится технологией, когда мы в состоянии управлять действиями по изменению состояний некоторого объекта. То есть технология - частный случай процесса.

"Процесс - кто-то исполняет и несет ответственность за исполнение технологии и очередности работ (по приоритетам) - управляет тоже, однако. Реализация процесса - объект управления."

Если рассматриваем процесс как объект - для него будет верно рассмотрение процессов управления им самим. Однако это уже управление технологией (процессом), то есть возникает иерархия.

"Состояние ресурсов, входов, исполнителей в ходе процесса меняется (износ, старение, пенсионные отчисления) - ресурсами опять же надо управлять. Ресурсы процесса - объект управления."

Это свои объекты управления со своими процессами.

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

В рассматриваемом контексте это не один процесс, а некоторое их множество, причём иерархически упорядоченное.

Я бы сформулировал иначе: "Процессом является последовательность изменений состояний во времени отдельно выделенного объекта под воздействием оказываемых на него для этих целей действий." (возьму на себя подобную смелость ).

Если рассматривать в более широком контексте сразу несколько объектов и их процессов (первичный, или "оригинальный" объект, технологию (процесс) управления изменениями его состояний, технологии управления ресурсами, бюджетами), как это делаете Вы, то получается рассмотрение не отдельного процесса со своим объектом, а иерархической системы со своими объектами, связями и процессами (технологиями) для каждого, причём обязательно с временнЫм атрибутом, но ведь для этого существуют свои понятия для описания, не так ли (мне кажется подходящим "динамическая система")?

С Вашей точки зрения в контексте "динамической системы" моё утверждение ""2. Каждый процесс- это объект управления (взгляд извне)" Вот с этим никак не могу согласиться в силу указанных выше причин." будет неверно. Однако с моей точки зрения - отдельно выделенного объекта и его процесса вне контекста "динамической системы" - видимо, будет верно. К сожалению, неиспользование привычного для меня понятия системы создало непонимание.

Со статьей с любопытством ознакомлюсь, если сообщите о публикации.
Оценки: /
06.04.2011 21:33
  от автора
  Репин
Привет, Виталий!

Да, статью потом надо будет, по-возможности, разместить на Финэксперте.
Оценки: /
06.04.2011 22:59
  от автора
  Елиферов Виталий
1.
К сожалению, неиспользование привычного для меня понятия системы создало непонимание.

А какое понятие Вы вкладываете в термин "система"?
Лично я пользуюсь определением из ИСО/МЭК 15288
4.17 система [system]
комбинация взаимодействующих элементов, организованных для того, чтобы
достичь одну или более заявленную цель.

Вроде бы ГОСТированный термин.
2.
Я бы сформулировал иначе: "Процессом является последовательность изменений состояний во времени отдельно выделенного объекта под воздействием оказываемых на него для этих целей действий." (возьму на себя подобную смелость ).

А если объектов (входов) - несколько (мост, коробка передач, двигатель + документация на каждый узел)?
А если ресурсов используемых для преобразования насчитывается больше десятка?
Это уже будет не "процесс"?
С уважением Виталий.
P.S. Вообще-то у меня написано и неопубликовано 4 статьи на темы вокруг процессов 2, скорее всего лягут в стол, а 2 вылизываю.
Оценки: /
06.04.2011 23:29
  от автора
  Репин
Новую книгу пустил на статьи, Виталий?
Оценки: /
07.04.2011 14:24
  от автора
  xtlan
"А какое понятие Вы вкладываете в термин "система"?"

Мне ближе другие определения, например, такое: "... система есть отражение в сознании субъекта (исследователя, наблюдателя) свойств объектов и их отношений в решении задачи исследования, познания ..."

Оценки: /
07.04.2011 14:55
  от автора
  xtlan
"А если объектов (входов) - несколько (мост, коробка передач, двигатель + документация на каждый узел)?
А если ресурсов используемых для преобразования насчитывается больше десятка?
Это уже будет не "процесс"? "

А разве входы - объекты процесса? Всё же объект должен быть для процесса один (главный или основной). И последовательность изменений его (основного объекта)состояний во времени и есть процесс.

Если же рассматриваем несколько объектов, то у каждого из них будут свои процессы, и для совокупности объектов будет не один процесс, а тоже их совокупность. То есть дело снова в точке зрения на выделенные для рассмотрения сущности, в иерархии и декомпозиции. А для нескольких объектов со своими процессами использование одного термина "процесс", относящегося к одному объекту, уже будет неправомерно.

Иными словами, если Вы рассматриваете процесс производства автомобиля, то автомобиль и есть его объект (основной). И в этом контексте рассмотрение в качестве объектов его частей с документацией вносит путаницу, поскольку из фокуса выходит сам основной объект. Как вариант - для частей использовать другие термины (например, "компоненты" ).

Аналогично именование ресурсов объектами в рамках контекста процесса сборки автомобиля (основного объекта) также вносит путаницу и создаёт расфокусированность.
Оценки: /
07.04.2011 17:53
  от автора
  Елиферов Виталий
Мне ближе другие определения, например, такое: "... система есть отражение в сознании субъекта (исследователя, наблюдателя) свойств объектов и их отношений в решении задачи исследования, познания ..."

А Вы не смешиваете в одно флаконе:
а) сама система - "как совокупность объектов и связей между ними"
б) модель системы - "отражение ВАЖНЫХ для данного рассмотрения СВОЙСТВ системы" - "в сознании субъекта"?
Одна и та же система может иметь несколько моделей представления. Очень хорошо написано об этом в книге Гради Буч "Объектно-ориентированный анализ и проектирование. с примерами приложений на С++" - на мой взгляд это классика.
С уважением Виталий.
Оценки: /
07.04.2011 22:58
  от автора
  Елиферов Виталий
Иными словами, если Вы рассматриваете процесс производства автомобиля, то автомобиль и есть его объект (основной). И в этом контексте рассмотрение в качестве объектов его частей с документацией вносит путаницу, поскольку из фокуса выходит сам основной объект. Как вариант - для частей использовать другие термины (например, "компоненты" ).

Правильно ли я понял, что автозавод должен выпустить продукт - автомобиль, а запаску, домкрат, инструкцию по эксплуатации, ПТС - отнести к необязательным "компонентам".
Вы пробовали купить и поставить на учет автомобиль без ПТС?
С уважением Виталий.
Оценки: /
08.04.2011 10:33
  от автора
  xtlan
"А Вы не смешиваете в одно флаконе:
а) сама система - "как совокупность объектов и связей между ними"
б) модель системы - "отражение ВАЖНЫХ для данного рассмотрения СВОЙСТВ системы" - "в сознании субъекта"?"

То есть Вы всё же смешиваете, и я это правильно подметил?

Я сначала дал своё определение системы, а потом его уточнил, приведя дословно определение другого автора, которое счёл более точным. Кстати, слова "ВАЖНЫХ" в определении нет...

Однако также известным фактом является то, что для моделей мы всегда используем упрощения, отсекая то, что считаем "неважным" для "... исследования, познания..."". Кажется, у Буча тоже есть высказывания на эту тему, не говоря уж о Стэнфорде Бире.

"Одна и та же система может иметь несколько моделей представления. Очень хорошо написано об этом в книге Гради Буч "Объектно-ориентированный анализ и проектирование. с примерами приложений на С++" - на мой взгляд это классика."

Сам разделяю эту точку зрения, и творчеством Буча, Рэмбо и Якобсона знаком.

"Правильно ли я понял, что автозавод должен выпустить продукт - автомобиль, а запаску, домкрат, инструкцию по эксплуатации, ПТС - отнести к необязательным "компонентам".
Вы пробовали купить и поставить на учет автомобиль без ПТС? "

Я веду речь о о том, как выглядит модель с данной точки зрения. Что вовсе не означает, что нет других точек зрения, в которых есть и запаска, и домкрат, и инструкция по эксплуатации... Кстати, которые могут не входить в само понятие автомобиль как некоего целостного объекта, а быть его аксессуарами и дополнительными средствами для вторичных целей, например, регистрации в ГИБДД.

И ещё: я веду речь о том, что если мы рассматриваем систему с одной точки зрения и ведём речь о ней с этой точки зрения, а потом меняем точку зрения и начинаем обсуждать систему с новой точки зрения, не сообщая читателю о смене точки зрения - возникает путаница.
Оценки: /
08.04.2011 22:46
  от автора
  Елиферов Виталий
Интересно Вы выражаетесь! Сначала у Вас система = отражение (то есть модель системы):
Мне ближе другие определения, например, такое: "... система есть отражение в сознании субъекта (исследователя, наблюдателя) свойств объектов и их отношений в решении задачи исследования, познания ..."

Затем Вы передергиваете мой вопрос к Вам:
"А Вы не смешиваете в одно флаконе:
а) сама система - "как совокупность объектов и связей между ними"
б) модель системы - "отражение ВАЖНЫХ для данного рассмотрения СВОЙСТВ системы" - "в сознании субъекта"?"
То есть Вы всё же смешиваете, и я это правильно подметил?

Мне кажется наоборот, что это я Вам указал на Ваше смешение понятий "система" и "модель системы" ("отражение системы в сознании субъекта" - таковы Ваши слова).
Действительно, Вы очень быстро меняете точку зрения. Но при построении модели системы так делать нельзя.
1. Повторите, пожалуйста, Ваши определения "системы" и "модели системы", чтобы исключить разногласия.
2. Подумайте, из каких составных частей состоит "услуга"? Что является в ней единым преобразуемым объектом при создании "услуги", которую потребляет клиент?
С уважением Виталий.
Оценки: /
08.04.2011 23:00
  от автора
  Елиферов Виталий
Я веду речь о о том, как выглядит модель с данной точки зрения. Что вовсе не означает, что нет других точек зрения, в которых есть и запаска, и домкрат, и инструкция по эксплуатации... Кстати, которые могут не входить в само понятие автомобиль как некоего целостного объекта, а быть его аксессуарами и дополнительными средствами для вторичных целей, например, регистрации в ГИБДД.

Правильно ли я понял, что "регистрация в ГИБДД вторична" и Вы готовы купить автомобиль на котором нельзя ездить, - без запаски, домкрата и ПТС?
С уважением Виталий.
Оценки: /
11.04.2011 14:50
  от автора
  xtlan
Гм... Давайте начнём сначала:

1. Ваше утверждение из статьи:

"При этом необходимо помнить, что под процессом (бизнес-процессом) мы понимаем, совокупность видов деятельности или объекты, которые целесообразно выделять и документировать в организации для основной деятельности и управления."

Мой вопрос:

"Всё-таки непонятно: бизнес-процессы - это совокупность видов деятельности или объекты? Вроде совершенно разные сущности, а мы их - отождествляем под определением "бизнес-процесс". Странно, как объект может быть процессом...".

Вопрос вызван тем, что из статьи непонятно, как одна и та же сущность - "процесс" - является одновременно и процессом, и объектом...

Ваш ответ:

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

Из Вашего ответа можно сделать следующие выводы:
1.1. Есть "объекты" - не процессы, и есть "объекты" - процессы. Разница между ними В СТАТЬЕ не определена. Определение самого процесса также отсутствует.
(Кто ж спорит, что не каждый объект есть процесс... Но утверждение о том, что наклеивание марки на конверт не может претендовать на процесс - спорно, поскольку зависит от степени детализации. Например: "Подготовить марку и конверт, смочить язык слюной, высунуть его изо рта, поднести марку к языку и смочить её клейкую сторону слюной с языка. Быстро поднести смоченную слюной марку к конверту и прижать в обозначенном месте для приклеивания. Исключение: при отсутствии марки или конверта или слюны язык не высовывать.". Чем не процесс? Все его атрибуты налицо: входы, выходы, ресурсы, управление.... )
1.2. Появилась новая точка зрения: процесс - объект управления (взгляд извне).
1.3. "Каждый "процесс - это совокупность действий по преобразованию...." (взгляд изнутри). При этом
1.4. Итак, у нас есть разные точки зрения на одну сущность - "процесс", которая с этих точек зрения меняет своё описание - то процесс, то объект. О том, что мы рассматриваем "процесс" с разных точек зрения, в статье речи нет.

Итог: переход с одной точки зрения на другую в отношении процессов в статье не оговорен, поэтому вызывает затруднения в восприятии и порождает вопросы.

2. Мои предыдущие комментарии к Вашим объяснениям:

2.1. "1. Не каждый "объект" может быть назван "процессом".".
Собственно, как раз в этом-то и был вопрос: исхожу из посылки, процесс не есть объект, а последовательность изменений состояний объекта во времени. Поэтому и возник вопрос..."

"2. Каждый процесс- это объект управления (взгляд извне)"
Вот с этим никак не могу согласиться в силу указанных выше причин."

Если оставаться на точке зрения на процесс "изнутри" - это так.

"3. Каждый "процесс - это совокупность действий по преобразованию...."
А вот это определение - с другой точки зрения. Когда рассматриваем, почему же объект меняет свои состояния во времени - оказывается, потому, что в отношении него мы применяем некоторые действия, которые способствуют изменению его состояний."

Это снова взгляд на процесс "изнутри".

3. Вы комментируете:

"Если я правильно понял, с Вашей точки зрения Процесс - это технология преобразования входа в выходы.
Но... Технологию - кто-то разработал и несет ответственность за ее эффективность (управляет технологией). Технология - объект управления.
Процесс - кто-то исполняет и несет ответственность за исполнение технологии и очередности работ (по приоритетам) - управляет тоже, однако. Реализация процесса - объект управления.
Состояние ресурсов, входов, исполнителей в ходе процесса меняется (износ, старение, пенсионные отчисления) - ресурсами опять же надо управлять. Ресурсы процесса - объект управления.
То есть, с точки зрения математической модели, начальное состояние процесса описывает многомерное пространство состояний (параметров объектов модели), которое в ходе выполнения процесса должно перейти в целевое пространство состояний (пошагово, по орграфу или сетям Петри).
Статья на эту тему уже написана мною в соавторстве с одним математиком, скоро вылижем ее и где-нибудь напечатаем."

Мои комментарии к Вашим:

"Если я правильно понял, с Вашей точки зрения Процесс - это технология преобразования входа в выходы. Но... Технологию - кто-то разработал и несет ответственность за ее эффективность (управляет технологией). Технология - объект управления."

Смотрю на процесс шире. Процесс для нас становится технологией, когда мы в состоянии управлять действиями по изменению состояний некоторого объекта. То есть технология - частный случай процесса.

"Процесс - кто-то исполняет и несет ответственность за исполнение технологии и очередности работ (по приоритетам) - управляет тоже, однако. Реализация процесса - объект управления."

Если рассматриваем процесс как объект - для него будет верно рассмотрение процессов управления им самим. Однако это уже управление технологией (процессом), то есть возникает иерархия.

"Состояние ресурсов, входов, исполнителей в ходе процесса меняется (износ, старение, пенсионные отчисления) - ресурсами опять же надо управлять. Ресурсы процесса - объект управления."

Это свои объекты управления со своими процессами.

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

В рассматриваемом контексте это не один процесс, а некоторое их множество, причём иерархически упорядоченное.

Я бы сформулировал иначе: "Процессом является последовательность изменений состояний во времени отдельно выделенного объекта под воздействием оказываемых на него для этих целей действий." (возьму на себя подобную смелость ).

Если рассматривать в более широком контексте сразу несколько объектов и их процессов (первичный, или "оригинальный" объект, технологию (процесс) управления изменениями его состояний, технологии управления ресурсами, бюджетами), как это делаете Вы, то получается рассмотрение не отдельного процесса со своим объектом, а иерархической системы со своими объектами, связями и процессами (технологиями) для каждого, причём обязательно с временнЫм атрибутом, но ведь для этого существуют свои понятия для описания, не так ли (мне кажется подходящим "динамическая система")?

С Вашей точки зрения в контексте "динамической системы" моё утверждение ""2. Каждый процесс- это объект управления (взгляд извне)" Вот с этим никак не могу согласиться в силу указанных выше причин." будет неверно. Однако с моей точки зрения - отдельно выделенного объекта и его процесса вне контекста "динамической системы" - видимо, будет верно. К сожалению, неиспользование привычного для меня понятия системы создало непонимание.

Со статьей с любопытством ознакомлюсь, если сообщите о публикации.


3.1. В своём комментарии я предлагаю ввести понятие динамической системы, так как мне её использование по отношению к "процессу"-"объекту" представляется более подходящим, поскольку Вы рассматриваете не выделенный процесс, а дополнительно и его окружение с другой точки зрения (извне).

3.2. Повторение: для рассмотрения не отдельно взятого процесса, а процесса в его окружении с другими объектами и процессами, мне представляется более подходящим использование понятия система.

4. Вы спрашиваете:

1.
К сожалению, неиспользование привычного для меня понятия системы создало непонимание.

А какое понятие Вы вкладываете в термин "система"?
Лично я пользуюсь определением из ИСО/МЭК 15288
4.17 система [system]
комбинация взаимодействующих элементов, организованных для того, чтобы
достичь одну или более заявленную цель.

Вроде бы ГОСТированный термин.

2.
Я бы сформулировал иначе: "Процессом является последовательность изменений состояний во времени отдельно выделенного объекта под воздействием оказываемых на него для этих целей действий." (возьму на себя подобную смелость ).

А если объектов (входов) - несколько (мост, коробка передач, двигатель + документация на каждый узел)?
А если ресурсов используемых для преобразования насчитывается больше десятка?
Это уже будет не "процесс"?

Я отвечаю:

"А какое понятие Вы вкладываете в термин "система"?"

Мне ближе другие определения, например, такое: "... система есть отражение в сознании субъекта (исследователя, наблюдателя) свойств объектов и их отношений в решении задачи исследования, познания ..."

"А если объектов (входов) - несколько (мост, коробка передач, двигатель + документация на каждый узел)?
А если ресурсов используемых для преобразования насчитывается больше десятка?
Это уже будет не "процесс"? "

А разве входы - объекты процесса? Всё же объект должен быть для процесса один (главный или основной). И последовательность изменений его (основного объекта)состояний во времени и есть процесс.

Если же рассматриваем несколько объектов, то у каждого из них будут свои процессы, и для совокупности объектов будет не один процесс, а тоже их совокупность. То есть дело снова в точке зрения на выделенные для рассмотрения сущности, в иерархии и декомпозиции. А для нескольких объектов со своими процессами использование одного термина "процесс", относящегося к одному объекту, уже будет неправомерно.

Иными словами, если Вы рассматриваете процесс производства автомобиля, то автомобиль и есть его объект (основной). И в этом контексте рассмотрение в качестве объектов его частей с документацией вносит путаницу, поскольку из фокуса выходит сам основной объект. Как вариант - для частей использовать другие термины (например, "компоненты" ).

Аналогично именование ресурсов объектами в рамках контекста процесса сборки автомобиля (основного объекта) также вносит путаницу и создаёт расфокусированность."


5. Вы обвиняете меня в том, что у меня путаница:

А Вы не смешиваете в одно флаконе:
а) сама система - "как совокупность объектов и связей между ними"
б) модель системы - "отражение ВАЖНЫХ для данного рассмотрения СВОЙСТВ системы" - "в сознании субъекта"?
Одна и та же система может иметь несколько моделей представления. Очень хорошо написано об этом в книге Гради Буч "Объектно-ориентированный анализ и проектирование. с примерами приложений на С++" - на мой взгляд это классика.

Комментирую сейчас:

5.1. Что-то я не нашёл в своих определениях системы в том виде, как Вы цитируете: "как совокупность объектов и связей между ними". Возможно, пропустил. Подскажите, пожалуйста, где я его приводил...
5.2. Я даю определение системы, которое считаю более точным ("... система есть отражение в сознании субъекта (исследователя, наблюдателя) свойств объектов и их отношений в решении задачи исследования, познания ..."), чем предложенное Вами ("Лично я пользуюсь определением из ИСО/МЭК 15288 4.17 система [system] комбинация взаимодействующих элементов, организованных для того, чтобы
достичь одну или более заявленную цель. Вроде бы ГОСТированный термин."), поскольку, к примеру, при рассмотрении солнечной системы цель, которую система должна достичь, мне неясна. А вот отражение в сознании субъекта её объектов и связей между ними (в отношении солнечной системы) - вполне понятно.

6. Я отвечаю:

"А Вы не смешиваете в одно флаконе:
а) сама система - "как совокупность объектов и связей между ними"
б) модель системы - "отражение ВАЖНЫХ для данного рассмотрения СВОЙСТВ системы" - "в сознании субъекта"?"

То есть Вы всё же смешиваете, и я это правильно подметил?

Я сначала дал своё определение системы, а потом его уточнил, приведя дословно определение другого автора, которое счёл более точным. Кстати, слова "ВАЖНЫХ" в определении нет...

Однако также известным фактом является то, что для моделей мы всегда используем упрощения, отсекая то, что считаем "неважным" для "... исследования, познания..."". Кажется, у Буча тоже есть высказывания на эту тему, не говоря уж о Стэнфорде Бире.

"Одна и та же система может иметь несколько моделей представления. Очень хорошо написано об этом в книге Гради Буч "Объектно-ориентированный анализ и проектирование. с примерами приложений на С++" - на мой взгляд это классика."

Сам разделяю эту точку зрения, и творчеством Буча, Рэмбо и Якобсона знаком.

"Правильно ли я понял, что автозавод должен выпустить продукт - автомобиль, а запаску, домкрат, инструкцию по эксплуатации, ПТС - отнести к необязательным "компонентам".
Вы пробовали купить и поставить на учет автомобиль без ПТС? "

Я веду речь о о том, как выглядит модель с данной точки зрения. Что вовсе не означает, что нет других точек зрения, в которых есть и запаска, и домкрат, и инструкция по эксплуатации... Кстати, которые могут не входить в само понятие автомобиль как некоего целостного объекта, а быть его аксессуарами и дополнительными средствами для вторичных целей, например, регистрации в ГИБДД.

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

7. Вы возмущаетесь (по моему мнению, это возмущение):

Интересно Вы выражаетесь! Сначала у Вас система = отражение (то есть модель системы):
Мне ближе другие определения, например, такое: "... система есть отражение в сознании субъекта (исследователя, наблюдателя) свойств объектов и их отношений в решении задачи исследования, познания ..."

Затем Вы передергиваете мой вопрос к Вам:
"А Вы не смешиваете в одно флаконе:
а) сама система - "как совокупность объектов и связей между ними"
б) модель системы - "отражение ВАЖНЫХ для данного рассмотрения СВОЙСТВ системы" - "в сознании субъекта"?"
То есть Вы всё же смешиваете, и я это правильно подметил?

Мне кажется наоборот, что это я Вам указал на Ваше смешение понятий "система" и "модель системы" ("отражение системы в сознании субъекта" - таковы Ваши слова).
Действительно, Вы очень быстро меняете точку зрения. Но при построении модели системы так делать нельзя.
1. Повторите, пожалуйста, Ваши определения "системы" и "модели системы", чтобы исключить разногласия.
2. Подумайте, из каких составных частей состоит "услуга"? Что является в ней единым преобразуемым объектом при создании "услуги", которую потребляет клиент?

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

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

7.2. Давайте будем точны в цитировании - у меня нет высказывания "отражение системы в сознании субъекта". Приписывание оппоненту того, что он не утверждает - вот это уже есть прямое передёргивание.

7.3. "Действительно, Вы очень быстро меняете точку зрения. Но при построении модели системы так делать нельзя."

Ну, точку зрения не меняют только дураки (не сам придумал, недавно вычитал сей афоризм ). Хотелось бы пример, где я её поменял.

Да, кстати, а почему нельзя менять точки зрения при построении модели системы? Вы же меняете их при рассмотрении процесса с "извне" на "изнутри" :-D При этом у Вас появляется много процессов вместо одного, и много объектов вместо одного, так что я и заметил, что в таком контексте использование понятия система будет более уместно.

7.4. "Повторите, пожалуйста, Ваши определения "системы" и "модели системы", чтобы исключить разногласия." - у меня нет определения "модели системы". У меня есть определение системы - "... система есть отражение в сознании субъекта (исследователя, наблюдателя) свойств объектов и их отношений в решении задачи исследования, познания ...".

7.5. Подумать могу, а зачем? Какова цель этих размышлений на заданную тему?

8. Я ездил на автомобиле без домкрата и запаски. Не попался. Потом купил. Ну и что? А какое отношение производство автомобиля имеет к его регистрации в ГИБДД после продажи покупателю? Или он уже на конвейере или сходе с него регистрируется в ГИБДД? А если его никто ещё не купил или не купит - процесс регистрации в ГИБДД будет всё равно "первичным", без которого автомобиль как объект не сможет существовать, так же, как и процесс его производства?



Оценки: /
12.04.2011 00:35
  от автора
  Елиферов Виталий
Так длинно я отвечать не могу, - нет времени.
1. Еще раз: Система - это объекты и связи между ними.
Модель системы - отражение ее в могзгах аналитиков (декомпозиция, анализ, синтез - классическая триада).
2. Стэнфорда Бира - нет. Есть Стаффорд Бир и Станфорд Оптнер - это 2 разных человека. Опять путаете.
3. Можно нарушать законы и гордиться этим, выводя правила, когда законы не нужны. Но это не правильный путь. Авто должно иметь все положенное оснащение, а ходит нужно только на зеленый свет.
С уважением Виталий.
Оценки: /
12.04.2011 11:09
  от автора
  xtlan
1. Ну, не сошлись во мнениях - бывает.
2. Верно, ошибся в написании имени, спасибо, что поправили. Бира с Оптнером - не путал.
3. Речь шла не о нарушении законов, а о точках зрения. Если бы все всегда жили только по законам, прогресс, видимо, умер бы уже давно.
Оценки: /
12.04.2011 11:45
  от автора
  Елиферов Виталий
2 xtlan
Маленькая тайна:
Чтобы окончательно Вас запутать скажу, что связи (стрелки) в модели системы, тоже являются объектами, могут иметь большое количество атрибутов (были примеры - более 30 атрибутов) и, в зависимости от требований модели, до 5-6 контекстных значений.
Мир сложен....
Оценки: /
14.04.2011 13:12
  от автора
  Богиня
Мир сложен..
Зачем-же усложнять его ещё больше

Оценки: /
15.04.2011 10:41
  от автора
  Елиферов Виталий
Богиня:
Мир сложен..
Зачем-же усложнять его ещё больше

Не бывает простых решений. Это только дедушка Ленин пытался решать сложные проблемы простыми методами. Помните: "... найти главное звено и вытащить всю цепь".
Хотя однажды после проекта гендир крупной компании (оборот 1-3 млрд. руб./ месяц) спросил меня: "А где та самая красная кнопка, нажав на которую я узнаю где у меня плохо и что надо сделать, чтобы стало хорошо" ( это цитата!!!!)
С уважением Виталий.
Оценки: /
18.04.2011 16:12
  от автора
  xtlan
"2 xtlan
Маленькая тайна:
Чтобы окончательно Вас запутать скажу, что связи (стрелки) в модели системы, тоже являются объектами, могут иметь большое количество атрибутов (были примеры - более 30 атрибутов) и, в зависимости от требований модели, до 5-6 контекстных значений.
Мир сложен...."

Хех... Не надейтесь

Добавить комментарий

Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
©  2010-2014 В.В. Репин. Сайт основан 3 февраля 2001 г.

Все права защищены. Частичное или полное копирование информации данного ресурса возможно только с разрешения владельца.

Регистрация
О Портале
Правила
Контакты
Новости
Библиотека
Энциклопедия
Литература и сайты
Группы
Мои страницы
Тесты
Форум
Доска объявлений