Честное говоря, нет никакого желания спорить. Я лишь выскажу одну мысль, которую считаю важной.

Поскольку здесь форум не менеджеров, а IT-специалистов, предлагаю вспомнить, что мы тут обсуждаем не только управленческие концепции, но и программные продукты, эти концепции реализующие. Так вот... У каждого программного продукта имеются свои плюсы и минусы. Или, чтобы быть более понятным, акценты и ограничения.

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

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

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

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

Теперь разберем другой вопрос. А именно, степени детализации информации при управлении. Если руководство производственного предприятия имеет понятие о пооперационном управлении и желает такое управление использовать, значит на предприятии необходимо ПО, способное его реализовать. И такому производству уже не подойдет ERP-система, в которой нет APS и/или MES, а имеется только MRP-II. С другой стороны, переход на пооперационное управление - это огромная головная боль, это сложно, это трудно! Менеджмент должен четко знать и понимать, идет ли он в эту сторону или не идет. Ели он сделал шаг, сказал "А", он должен идти до конца, как говорится, "сквозь раскаты грома и вой бури". Если нет уверенности, то лучше этот первый шаг не делать - цель, скорее всего, достигнута не будет, а вот головной боли существенно прибавится. Если объемно-календарное планирование - это предел мечтаний, то имеет смысл выбирать продукты, реализующие MRP-II. Но при этом заранее для себя четко определиться, что в ближайшие несколько десятилетий никто в руководстве о пооперационном управлении не заикнется.

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

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

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

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

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

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

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

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

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

guest_20040621Я говорил ровно то же самое: 90% софта написано криворукими ламерами. Причем, говорил абсолютно не имея желания никого обидеть, просто констатируя факт.Нет, дело не в "ламерах", а в объективных законах природы. Каждый софт написан для реализации определенного круга задач, а не для взмахивания "волшебной палочкой" с произнесением любых желаний. Это - объективная реальность, и никто ее изменить не в состоянии.

guest_20040621> Есть программные продукты, оринтированные на долгую
> и нудную их "первоначальную настройку".

Другими словами, кроме криворуких ламеров в создании некоторых продуктов приняли активное (более необходимого) участие криворукие менеджеры проекта. ;)Вы опять не так меня поняли. Есть продукты, нацеленные на определенную концепцию их использования. На то, что 95% всех настроек делается ПЕРЕД использованием продукта, а не ВО ВРЕМЯ . Дело не в кривых руках, а в том, что выполнить все желания всех и обо всем - невозможно. Нет ее, "волшебной палочки". Есть инструменты, каждый из которых предназначен для своих целей. Если заказчик не может определиться с целями, ему никто не сможет помочь.

guest_20040621И есть продукты, реализованные на приемлемом уровне. Конечно, кто б спорил. Те самые 10%. Только принадлежность к этим 10% - условна и конечному пользователю не очевидна.У этих продуктов имеются свои недостатки. В них, например, не встроена реализация сложных математических алгоримов (таки как APS, Closed Loop MRP, обработки 3-хмерной графики), которые имеют более тесные привязки к конкретным параметрам. Поэтому либо абсолютная гибкость без предварительной привязки к чему-либо, либо что-либо конкретное, но уже с заведомо ограниченной гибкостью. Я считаю, что в большинстве случаев необходимо использовать комбинацию того и этого. Вариабельная часть должна быть максимально вынесена в ПО с максимальной гибкостью. Специфические алгоритмы должны реализовываться специфическими программами.

guest_20040621> "и то, и другое" - это из области фантастики, а не реальности.
На самом деле совместить это отнюдь не так сложно, как Вы пытаетесь показать.Вот и прекрасно! Совместите пожалуйста. :) Сделайте универсальную супер-пупер-CAD-CAM-BPM-ERP-EAI-SCADA-систему, заткните за пояс SAP, Microsoft. Oracle и всех прочих... :)

guest_20040621А обратить внимание я Вам предлагаю вот на что: предприятие за свои деньги абсолютно добровольно получает наркотическую зависимость от конкретных стандартов, моделей, методов управления и пр. и, естественно, от внедренцев этого... хм... программного обеспечения. Причем, программного обеспечения, которое во-первых, потеряло актуальность еще позавчера, во-вторых, несет с собой следы жизнедеятельности всех криворуких ламеров, поучаствовавших в его создании (больше срок существования продукта - больше экскрементов), в-третьих, абсолютно без вариантов безболезненной миграции. И Вы - как внедренец - это прекрасно понимаете. Так вот imho было бы честно, если бы и заказчик это знал. Только кто ж ему это объяснит? Ему будут рассказывать о том, что ему "нужно определиться" и про "общеизвестные в IT принципы".Вы, наверное, думаете, что я представляю внедренческую фирму, консультантов или вендора. Я представляю интересы ЗАКАЗЧИКА . И мне приходится очень трудно. В начале года я передал руководству список из 20 вопросов. Ответы на которые до сих пор не получил. Самое главное - это получить озвученные цели .
"Нужно, чтобы заказчик это знал" - знал что? Что все кругом ламеры, включая него самого? Или чтобы он знал, что "волшебной палочки" не существует? По-моему, второе.

WJGarya писал, что ДО принятия решения о покупке ПО предприятие должно определиться с концепцией управления. И понятно, что после того, как выбор сделан, менять все обратно уже поздновато. И если все же заказчика предупреждают, что ему "нужно определиться", то это означает, что заказчик должен сделать выбор, будучи в здравом уме и трезвой памяти. А не то, что заказчик "уже попал" и обратной дороги у него нет.Спасибо, WJ... :)