По-моему, тема начинает скатываться к материям, совершенно не имеющим никакого отношения к "ERP и учетным системам".

Stann, тема, которую Вы затронули, весьма обширна. Предлагаю здесь ее не развивать. Я специально добавил Вас в список посетителей ЗПТ, чтобы Вы имели возможность подключиться к ее обсуждению , если у Вас есть такое желание.

Хочу обратить внимание аудитории, что A_S_U уже не может опонировать в данном треде.

По сути вопроса хочу подчеркнуть, что как оппонент A_S_U я ничего не имею против теории систем, как одной из арсенала подходов к управлению. TQM - лично для меня тоже " один из... ", хотя, может быть и более понятный и проще реализуемый на практике. Фактически суть нашего с A_S_U диспута свелась к тому, что я предполагал наличие у любого подхода некоторой сферы наиболее благоприятных условий для его применений и наличия условий (ограничений), при выполнении которых данный подход имеет смысл или не имеет смысла применять. Мой оппонент фактически заявил, что этот вывод некорректен, что кроме теории систем реально никаких других подходов нет и быть не может, поскольку теория систем - это точная наука а все прочие - это "бульварщина". Причем, теоррия систем заведомо не соедржит в себе никаких ограничений, и ее имеет смысл задействовать всегда и везде. Прежде, например, он утверждал, что теория систем - это панацея: http://www.sql.ru/forum/actualthread.aspx?tid=104522&pg=12󽶩 ASU Garya ASUКстати, не задумывались о причинах, по которым экспертные системы не стали панацеей?А предлагаемые Вами методы стали панацеей?Да, безусловно. Поскольку возвращение смысла тождественно отказу от бессмыслицы. А это без сомнения панацея :)Теперь он, правда, начал высказываться более осторожно: A_S_U GaryaУ меня складывается такое ощущение, что Вы таки нашли философский камень... :) Garya, я не искал и не находил «философских камней»... Ваши ощущения Вас обманывают.. К сожалению, обсуждение прервалось до того, как в нем была поставлена точка.

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

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

Во-вторых, ограничения практического применения теории систем на самом деле существуют. На двух наиболее существенных из них делает акцент Абдикеев - на трудоемкости детализации сложных систем и на черезмерной академичности данной области знания. На оба этих ограничения нам "посчастливилось" наткнуться в диспуте двухлетней давности. Сначала нам удалось выяснить, что попытки применения на практике этой области знания не приводят к решению задач оптимизации и автоматизации некоторых специфических аспектов управления, касающихся управляющих воздействий низового уровня : GaryaПроцесс управления пронизывает все структуры предприятия. Управляющие воздействия, проходя через многие иерархии структуры предприятия, передаются в конечном итоге на резцы станков, на колеса транспортных средств и на руки конструктора и технологаВ частности, использование программного продукта, базирующегося на теории систем и разработанного A_S_U, не позволяет заменить собой SCADA, CAD и CAM системы. Я не утверждаю, что BPM-системы позволяют их заменить, но ведь я и не утверждал, что BPM-система - это панацея. В конце концов, она тоже имеет свои ограничения (в частности, она ориентирована на выполнение многократно повторяющихся операций).

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

Еще раз отмечу, что я хуже A_S_U ориентируюсь в теории систем, но некоторые начальные посылки, озвученные моим оппонентом меня смутили еще во времена нашего старого спора. И до сих пор я не вплоне понимаю, каким образом можно выстраивать модель системы только из одной цели и ее элементов. А как же доступность инструментариев? Эту тему мы обсуждали давно , и тогда ASU не смог толком объяснить, каким образом система может порекомендовать воспользоваться динамитом, если она изначально не имеет никакого представления о существовании этого самого динамита. Я тогда высказал предположение, что в реальной жизни связь между причинами и следствиями гораздо более сложная - она предполагает рекурентную связку имеющихся средств достижения и целей, которые в принципе могут быть этими средствами достигнуты. Достижение новых целей дает в руки новые инструменты, новые инструменты позволяют ставить перед собой новые цели. Именно таким образом реальная система развивается - отталкивается от прежних достижений, достигая новых и после этого выбирая для себя следующую цель, достижимость которой оценивается исходя из имеющихся в распоряжении средств ее достижения. Новые достижения синтезируют новые средства. Новые средства синтезируют новые цели. По утверждениям же ASU я понял так, что он один раз выставляет целеполагание и после этого что-то там подкручивает в слабых связях, цель же у него остается постоянной (может быть, я его и не совсем правильно понял).

Нет, я ни в коем случае не хочу охаять теорию систем. Просто я не верю, что она собой может всё-всё-всё заменить.

И еще два слова о "напримерах", которые так не нравятся A_S_U. Так вот, я совсем иначе отношусь к этим самым "напримерам". Потому что именно благодаря им я могу понять, в каких случаях и каким образом достигается выигрыш. Вот ASU в топике двухлетней давности рассказал, каких выдающихся успехов достигли конкретные предприятия, которые использовали предлагаемый им подход. Почему бы ему не изложить их успехи как раз в ракурсе этого самого "напримера"? Почему бы не показать, что с помощью его методики достигается не только повышение ритмичности, снижение уровня материальных запасов и повышение качества, но что-то еще? Или, допустим, показать, что эти показатели улучшаются существенно более глубоко, нежели другими способами. Или показать, хотя бы на одном-единственном "напримере", в какой именно ситуации достигается специфический эффект, который недостижим методами TOC, TQM, JIT, проектного управления и т.д. и т.п. Мне ведь не нужно сразу всё дао, мне достаточно одного-единственного примера, чтобы согласиться, что да, в некоторых ситуациях теория систем способна достичь более серьезных успехов. Откуда же такое нежелание озвучить этот самый "например"? Ведь любое фактическое применение любой теории автоматически превращает ее использование в один конкретный "например". Разве мы не должны заранее быть уверены, что тот "например", который у нас скорее всего получится, будет лучше того "напрмера", который у нас получится при попытке следования TOC или TQM?

Мне очень жаль, что опонент отказался дальше участвовать в разговоре. Есть надежда, что он еще передумает...

Проба сил№Ответьте как верифицировать нарисованную схему? Просто и понятно... а потом можете сколько угодно говорить о Высоком... КОМУ верифицировать и для чего?
Вот на одном из наших заводов процессный менеджер сам составил схему бизнес-процесса. Он САМ отвечает за качество ее работы. Первые проблемы выявляются "на лету" - в процессе работы в BPM-системе по нарисованной схеме. Возникла проблема - изменяется схема таким образом, чтобы подобные проблемы больше не возникали, и выполнение бизнес-процесса уже выполняется по измененной схеме. Когда явные проблемы перестанут случаться, их нужно будет выискивать. Нужно будет внимательно смотреть на схему - тому самому процессному менеджеру, который ее нарисовал и который несет ответственность за качество ее работы - и пытаться понять, где, что и каким образом еще может быть улучшено. Когда все возможные улучшения, выявляемые "на глазок" также будут выполнены, пройдет уже немало времени. К тому моменту наберется массив выполненных экземпляров бизнес-процесса ("длиных транзакций"), который можно проанализировать по KPI. Например, выявить участки, на которых происходят максимальные потери времени на всякого рода согласования. Сделать это можно также просто "окинув взглядом" имеющуюся статистику. Таким образом появляются "подсказки", в какую сторону можно копать дальше, чтобы улучшить схему. Только на одном этом способе можно очень долго крутить цикл PDCA. Когда же возникнет ощущение, что улучшать дальше нечего, на полученную ранее статистику "натравливаются" методы статистического управления качеством. Если на каких-либо участках выявляются отклонения контролируемых параметров за пределы +/-3 сигмы, значит на данном участке процесс нестабилен. Значит, на этом участке действуют какие-то детерминированные составляющие (факторы), действие которых выпадает за рамки системы управления (являются не контролируемыми). Медитируем на тему поиска этих факторов, выявляем их и опять модифицируем схему таким образом, чтобы эти факторы были либо включены в состав бизнес-процесса, либо были просто устранены. Таким образом, стабилизируем бизнес-процесс (заметьте, всё это делает процессный менеджер, а не консультанты!). Когда процесс стабилизирован (на всех его фазах контролируемые параметры не выходят за пределы +/-3 сигмы), применяя методы Тагути для оценки качества, начинаем улучшать качество на каждом шаге бизнес-процесса. Опираясь на них, цикл PDCA можно потом крутить хоть до бесконечности. Можно использовать совокупность нескольких способов одновременно. Можно еще пришпандорить элементарный здравый смысл и интуицию. В любом случае помогать проводить верификацию схемы бизнес-процесса позволяет производить ее величество ПРАКТИКА . Потому что схема не просто "нарисована", она еще и реально запущена в работу. Поэтому менеджер, реально управляющий процессом не может, не имеет права чего-либо не понимать или плохо себе представлять. Он САМ рисует бизнес-процесс и САМ его верифицирует. И задача "разобраться в схеме" перед ним не стоит. Поскольку он сам ее рисовал, наверняка он ее помнит почти наизусть. Верификация схемы должна производиться ПОСТОЯННО , на всем протяжении ее уже фактической работы. Это важнейшая составляющая цикла PDCA, конкретно C="check". За один год схема, постоянно "немножко изменяясь", может измениться до такой степени, что уже не будет иметь ничего общего по сравнению с той гусеницей, из которой она выросла.

Я ответил на Ваш вопрос? Или под верификацией Вы имели в виду что-то другое?

iscrafmПусть фигня, зато со штампиком "На предприятии ISO9000".Мне тоже не нравится слепое увлечение модой и штампиками. Именно по этому поводу я уже высказывался: GaryaДостижение форматов менеджмента TQM - это ЦЕЛЬ, которую также можно пытаться достичь в рамках философии Деминга. Совсем не обязательно пытаться сразу описать все бизнес-процессы. Это слишком трудоемкая задача, и в прорцессе ее выполнения весьма вероятно получить груду неточностей и откровенных ошибок. Лучше описывать по маленьким кусочкам - и сразу запускать эти кусочки в работу. Потом расширять и уточнять описанные бизнес-процессы, реализуя цикл PDCA. И постепенно охватить всё предприятие. Возможно, на эту работу понадобится не 1 месяц, а 2 года. Но она будет РЕАЛЬНО сделана. Да, вот прямо завтра сертификат получен не будет... Ну и что? Разве сертификат важнее следования философии эффективного управления?