Что есть бизнес, как не систематическое применение знаний и умений, поиск новых знаний и их овеществление (или, если угодно, «отоваривание»)?

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

Скорость изменения современного бизнеса такова, что в ближайшую десятилетку он изменится больше, чем за все время своего существования.

О стабильности остается только мечтать, ключевыми факторами давно стали изменения и скорость.

При этом национальные особенности Российского бизнеса накладывают свой отпечаток, еще сильнее отдаляя нас от стабильности (см. статью по адресу [ссылка]

В 80-90-е годы все было совсем не так и у нас и у «них». Мы усиленно занимались плановой экономикой, «они» управляли качеством и «реинженирили» бизнес.

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

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

При огромной скорости изменений, формализация бизнес-процессов, описание их как технологии постепенно будет становится невозможным, потому, что время затрачиваемое на формализацию процесса с последующей его автоматизацией все чаще и чаще будет превышать время существования самого процесса. Ресурсы, необходимые для формализации, будут превышать производственные ресурсы компаний. Штат аналитиков, в обязанности которых входит «реинжиниринг» будет неуклонно расти. И если провести аналогию с «телефонистками Белла», то через десяток лет каждый взрослый человек в возрасте от 20 до 35-ти лет будет занят системным анализом.

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

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

Рад приветствовать Вас в этой дискуссии.
Константин Глазин

Вопросы плана:
"Можем ли мы создать такую управленческую систему, которая будет автоматически и оперативно адаптироваться к реалиям бизнеса? Если это возможно, то как это сделать?" напоминают мне призывы советских времен к АСУчиванию всего чего только можно и также русских народовольцев и демократов a-la г-н Чернышевский в их попытках создать механизм генерации "добра" и "справедливого общества" чтобы затем всем дружно зажить счастливо ничего не делая.

Что-то мне говорит о тщетности попыток и бессмысленности вопросов, по крайней мере в такой их широкой формулировке.

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

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

Семантические сети, как средство формализации бизнеса ... интересно. Прямо таки автоматическое интеллектуальное предприятие получается. По-моему до этого еще далековато...

Да и вопрос что чем там расширяется - ярлыком или еще чем - вторичен. Не лучше ли нам обсудить методологии, позволяющие решать перечисленные проблемы, а не углубляться в «…цепочки (частный случай сети) из трёх объектов-значений…»?

Так что за методологию Вы имели ввиду, когда говорили что «можно создать такую управленческую систему»?

Нет, не так уж и далеко. В 2002 году начнётся госпрограмма "интеллектуальное производственное предприятие". Надеюсь поучаствовать.

>>> Так что за методологию Вы имели ввиду, когда говорили что «можно создать такую управленческую систему»?

Я имел ввиду методологию динамичных семантических сетей. Она включает алгебру открытых сетей. Имею ввиду те самые цепочки с ярлычками:)
Можно подробнее, но здесь мало места. Может быть интереснее рассмотреть этот подход на примерах "перечисленных проблем". Начните перечислять проблемы и мы продолжим диалог.

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

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

Потом эти «чернышевские» могут еще и документ накатать – «концепция автоматизации» (или Vision scope, например), которая определяет стратегию построения информационной системы.

Ну, а потом, они могут приступить к построению системы. Бестолковые. Другие, в это время, уже успевают пройти весь путь от самого начала и до окончания.

Вот только окончание, в таких случаях, предсказуемо – надгробная плита над системой автоматизации, бездарно потраченное время и средства и стойкое отвращение руководителей всех уровней к слову «автоматизация».

С уважением,
Глазин Константин

Константин, но нельзя же построить универсальную сиситему "ВООБЩЕ", это утопия. Как бы красива, логична и стройна она не была на бумаге, жизнь внесет в неё свои коррективы и запросто разрушит её. Пример с Чернышевским был к месту, ведь были же последователи, организовывали эти мастерские и получалось совсем не то, что в книжке.
Сама по себе автоматизция нужна, тут и спорить нечего. Но создать некий абсолютный механизм мне лично не представляется возможным. Попытка охватить в ней всё мыслимое и немыслимое приведёт к усложненной функциональности в ущерб простоте и ясности. А ведь преполагалось, что все работники предприятия смогут в той или иной степени пользоваться ею, но она в результате окажется слишком сложна даже для посвященных.
У Брукса описана каскадная модель планирования, как порочная. Я, пожалуй, к его мнению присоединюсь. Такое линейное планирование рождает мёртвые системы. Вы опишите вашу концепцию, попытаетесть её внедрить сообразно плану и на выходе получите в худшем случае мертвеца, в лучшем, если начнете отходить от плана, - совершенно не то, что планировали.

Тоже соглашусь с Бруксом.
При каскадном планировании сверху в меняющихся условиях возникает встречный поток измений. Для поддержания целостности (смысловой:) плана придётся множить число координаторов и делать запасы ресерсов.
Есть иной подход. При ситуационном управлении работами их смысловая целостность поддерживается технологическими картами, т.е. технологией производства работ. А истинное время начала работ как уж получится. Для аварийных событий и обстоятельств подход тот же. Выделяется ресурс для аварийной команды. Он может быть и виртуальным (создаваться по технологической карте в случае той самой аварии).
Замечу, что при таком технологическом планировании и ситуационном управлении привычные всем диаграммы Ганта играют иллюстративную, вспомогательную роль.

Господа!

А как бы вы проектировали автопилот самолета?

А так же!!

При всей своей сложности эта задача тривиальна в том смысле, что автопилот не встречается на своем пути с упрямой волей управленцев/управляемых :))

Анастасия!

SADT, UML, Booch - вполне универсальны, просты и доступны. SADT просто поражает своей простотой, особенно в той части, которая вошла в IDEF0. Эти простые и универсальные языки позволяют создать сколь угодно сложную модель.

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

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

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

Эк Вы загнули!

А я вот приведу пример попроще.
В компании есть отдел финансового анализа, в котором весьма продвинутые сотрудники. Так вот, один из них создал очень полезную и за пределами отдела программу на VBA для Ёкселя.

Другими словами, внес дополнения в IT-модель предприятия. Его опыт обобщить-бы и распространить по всем подразделениям. Но реально работающего механизма, который позволил бы это сделать, нет.

А вот, если бы был - это и было бы элементом автоформализации.

Вот так, и никакого понимания "множества локальных языков".

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

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

Можно. Транспортов существует превеликое множество, начиная с курьера и заканчивая интранетом.

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

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

Что же касается "систему городить", то позволю себе повториться:

Цели автоформализации:

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

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

3. Настройка и адаптация созданного информационно сервиса к изменениям с минимальными затратами и временными потерями.

Здесь ни слова об автоматизированной системе. Сначала желательно было бы определиться что и как нам делать, а уж потом автоматизироваться.

Так что давайте, для начала, попробуем ответить на вопрос: как вовлечь в процесс формирования информационных услуг не только специалистов IT-подразделений? Было бы просто здорово, если бы Вы сказали:
1. Делаем то-то …
2. Делаем то-то …
3. Получаем вовлеченных специалистов.

я уже немного ответила на этот вопрос ниже в " Re: Re: Ну что Вы, в самом деле!".
что можно сделать?
1. Рассылать информационные сообщения.
2. Собирать на маленькие совещания всех, кому ваши новые разработки могут быть полезны и интересны, назовите их тренинги и проводите раз в месяц хотя бы.
3. Найдите хотя бы пару человек, которые на ваш взгляд согласятся попробовать фичу в существующем виде. Их опыт поможет вам в дальнейшем проектировании и плюс они сами будут рекомендовать её коллегам. Или не будут, если она неудачна. Включайте конечного юзера в процесс. Юзер вам не враг:)
4. В вашей фирме наверняка есть техникал саппорт,который ставит ворды и ёксели пользователям. Раздайте вашу примочку им, пусть они ставят её вместе с Экселем, этому человеку пользователь доверяет, его мнение будет для него немаловажно. Он же жоверяет ему, когда тот приносит последнюю версию ВинЗипа.
5. Создать интранет (КИС или как хотите назовите) и публикуйте там в разделе Инструметарий. В самом деле ведь всё это уже наверняка существует у вас, только в другом виде. Где-то всегда есть папка Distr или Soft, открытая для свободного доступа. Но не все о ней знают и ей пользуются.

Если вы набрали хотя бы N% пользователей вашей фичи на начальном этапе, можно уже давить на начальтво, чтобы её пространение было в фирме обязательным. Можно конечно и сразу к начальству пойти, но юзер фичу возьмет, а пользоваться не будет. Так что идите снизу.

Такая технология осбенно хорошо работает, когда в компании штук двадцать-тидцать фич в день создается :-))

А у вас их действительно 20-30? И все стоят того, чтобы внедрять? А если так, почему во вводных это не присутствовало? Константин, так у вас задача не фичу внедрить, внедрить одну из 20 фич. Это несколько меняет дело. С каждым разом вы всё усложняете задачу.:) Тогда 20 фич уже пора объединять в программный продукт. Или набор плагинов. Толкать по одной фиче - это непозволительная роскошь.:)

Пожалуйста, воздержитесь от подобного рода выражений хотя бы в поле "Тема" отправляемых Вами сообщений.

Уважаемый Андрей, а чем выражение "ёксель-моксель" отличается от выражения "ё-моё"? Если вы читали дискуссию, то Ёксель - это всего лишь Эксель, он же MS Excel. Возможно такое название программного продукта оскорбляет слух компании Майкрософт. Я это учту.

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

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

С уважением
Анастасия

в связи с поступлением новых данных обобщим:

1. Есть полезная и нужная фича, которая работает только у одного человека, и совершенно не известно будет ли она работать у других и нужна ли она им в таком виде.

Проблемы:

1. Фича не интергирована, имеет мало функций и узкую область применения.
2. в компании в месяц выходит еще 20-30 фич, все они тоже требуют внедрения.
3. Отсутствует система информации о новых программных продуктах. Конечный пользователь ничего о них не знает.
4. Отсутствует тренинг, то есть люди которые могли бы научить, как этой штукой пользоваться и объяснить её преимущества.
5. Фича требует доработки, а это займет время. За это время она может устареть или появятся другие фичи, которые срочно надо будет внедрять.

Задача:

Как доработать и внедрить эту штуку в кратчайшие сроки, чтобы пользователь сказал "Спасибо, давайте еще!"

А если можно просто прокричать, то и ещё проще общаться.

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

Метод Ваш испробован в Шанхае.
Архитектура известной красоты. Хотя ведь живут же там люди.

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

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

Александр!

Что Вы все в высоких материях летаете?

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

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

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

Так как это сделать в рамках столь активно рекламируемой Вами "уже работающей технологии"?

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

Как? Варианты:
1. Собрать совещание, рассказать и показать.
2. Разослать по электронной почте описание использования и преимуществ.
3. Повесить на интранете.
4. Распечатать всё тоже самое в немерянных количествах и разбросать по всем офисам.
5. Звонить по телефону каждому заинтересованному лицу и объяснять лично, что это за штука.

Вобщем выступать в роли пушера.

Здорово у Вас все получилось!

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

Если речь шла о Экселе, то не думаю, что такая уж там сложная интеграция с приложениями возникнет. Константин, вы тогда не упоминали, что проблемы с интеграцией есть. Речь шла о продукте, который надо протолкнуть пользователю.
Если серьёзно, то она же у кого-то работает? Так есть значит и еще люди с теми же требованиями и условиями. Значит на них можно эту фичу обкатать. Чтобы учесть все функциональные возможности надо знать, как и что пользователь использует. Он вам сам расскажет, что ему нравится, что нет и с чем это работает, а с чем не работает. а надо чтобы работало.
Вы опять к каскадной модели возвращаетесь:)) Сначала всё продумать, всё учесть.. Но у вас есть продукт, он уже придуман, он даже частично сделан, то есть работает в окнкретных условиях. Запустите его и одновременно работайте над расширением функций и совместимостью. Так называемый принцип второй модели. У вас будет и возможность изучить жизнеспособность идеи, и тестирование и внедрение расширений.

И как вам удаётся простую ситуацию излагать таким запутанным языком?:) Я прекланяюсь перед этим, поскольу сама таким талантом не обладаю.
Парень изобрел колесо. Вокруг все таскают волоком. Парень сидит со своим колесом и думает - Как бы встроить эту штуку в их бизнес-модель? Он придумывает систему, как бы это колесо им предложить, ненавязчиво. Продумывает, с кого начать, пишет целый труд о возможной пользе структурного объединения колеса и пары досок. Пока он пишет, кому-то уже эта же идея приходит в голову, он уже всё показал и рассказал просто, так чтобы поняли. Можно, конечно, назвать это дело - информационная среда, которая что-то там суммирует в массиве. А можно проще - наглядный показ юзеру что ему от этой штуки будет хорошо.

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

Несомненно!

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

Хотите вы того или нет - в голове каждого участника бизнеса складывается своя модель. И чем более близкими будут эти модели в разных головах, тем согласованнее будут общие услилия.

Не Чернышевский, а Мэри Шелли:) Такая гибкая самообучающая система управления уже есть - это человек, то есть хомо сапиенс. Создание его прототипа потерпело фиаско, Франкенштейн не удался.

Проблема не в воспроизводстве полного или частичного аналога человека-разумного. Лучше ребенка родить :)~
Проблема в наилучшей организации производительного коллективного труда. Точнее, - в гибкой организации ресурсов для труда коллектива, объединённого общей целью.

Ну да, организация коллективного труда - это, как я понимаю, некий искусственный разум, который не даст работникам делать всякие глупости в рабочее время, этакий глобальный fool proof. И если этот разум внедрить, то все механизмы и люди будут работать правильно и производительно, потому что Разум им по-другому и не позволит. Люди, конечно, будут сопротивляться, пытаться Разум обманывать, придумывать разные хитрые ходы, норовить строить бизнес не по правилам, но Разум будет гибко на это реагировать и бить их по рукам. Вы знаете аналог такого Разума?:) Я знаю только один и я его уже назвала.

Действительно, лучше ребенка родить:)

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

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

Вы исходите из необходимости принуждения к труду.
Есть не только кнут, но и пряник.

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

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

Из нашего опыта проектов следует, что все они начинались в период обострения проблем, когда стало невозможным не замечать проблем. Только вот надо, чтобы хозяин бизнеса захотел, а не только его управленец. Было и так, что сделали и пользу принесли, планы развития построили, а потом пришел "лесник" и все коту под хвост.
Согласен, надо работать с мозгами хозяев и менеджеров, но это уже групповая психотерапия. Наука пока молчит..

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

Я бы хотел узнать Ваше мнение по поводу следующего обстоятельства.

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

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

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

Спасибо.

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

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

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

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

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

Цели автоформализации:

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

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

3. Настройка и адаптация созданного информационно сервиса к изменениям с минимальными затратами и временными потерями.

Используемые термины.

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

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

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

Задачи:

1. Обсудить существующие методики, позволяющие внедрить автоформализацию
2. Выявить их достоинства и недостатки
3. Возможно, предложить что-либо новое (кто знает что именно?)

Ключевые слова.

Сервис, доступность, непрерывность, децентрализация, саморегулирование, моделирование.

Прошу всех присоединяться к дискуссии.

Константин Глазин

Прекрасное построение смыслового материала. Четко изложен каркас концепции Автоформализации бизнеса.

Всё прекрасно изложено.
А о чём дискутировать?
Ведь именно такие технологии нужны для управления операциями в бизнесе.

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

Почти уверен, что участники данной дискуссии имели в виду разные варианты ;)

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

Почти уверен, что участники данной дискуссии имели в виду разные варианты ;)

С ходу реплика:
"«Реинженеры» способны рисовать красивые и качественные модели и схемы"
Принципиальна разница между моделью и схемой. Модель позволяет моделировать, извините за тавтологию. То есть, схема "правильного" реинжиниринга видится такой:

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

"Принципиальна разница между моделью и схемой"????

IDEF - это модели или схемы?

Сергей, Вы когда ни будь пробовали создать модель предприятия, состоящего из 300 подразделений? С трудноперечислимым количеством бизнесов? Вовлеченного в отношения с аффилированными компаниями?

Сколько Вам потребуется на это времени? И как по Вашему состояни системы не изменится за время моделирования?

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

Жду ответов.

1. IDEF - это язык описания, использовать его можно и для схем (легко), и для моделей (сложнее).
2. Не пробовал.
3. Вы абсолютно правы, централизованно построить детальную модель всего бизнеса невозможно. Так ведь и не нужно! Весь фокус в уровне детализации и в делегировании полномочий. Обобщенную модель строит штаб-квартира холдинга, каждое подразделение раскрывает свою часть этой модели. С обратной связью то же самое: по мере движения наверх показатели консолидируются.
4. Естественно, многомерная оптимизация нереальна, поэтому работаем по двумерным, максимум - трехмерным сечениям.
4.1. Организационно-функциональный срез (кто-что). Расписываем функции бизнеса, накладываем на оргструктуру, приводим второе в соответствие с первым. Детализируем оргструктуру до уровня штатного расписания.
4.2. Функционально-технологический срез (что-как). В каждом сегменте (маркетинг, финансы, производство и т.д.) прописываем бизнес-процессы, оптимизируем их. Дальше получаем еще три среза - движение материальных средств, документооборот и должностные инструкции.
4.3. Вводим количественную (финансовую) оценку. Из 4.1. вырастает бюджет накладных расходов, из 4.2. - операционные бюджеты.
4.4. Формируем иерархическую систему индикаторов состояния бизнеса.
4.5. Прописываем информационные потоки, утверждаем модель структуры данных. Вот теперь можно приступать к автоматизации, раньше бессмысленно.
4.5. Запускаем контур стратегического управления.
4.6. Реагируем на изменения индикаторов под влиянием рыночной среды - оперативно вносим изменения в работающую модель.
4.7. После обкатки можно попробовать перейти к процессно-ролевой модели (кто-что-как).
Вот.

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

2. А я пробовал :-))

3. Совершенно верно! Иными словами, решаются задачи анализа и синтеза. Весь вопрос в том, как организовать процесс таким образом, чтобы решения, возникающие в конкретных подразделениях, могли бы быть распространены (при необходимости) на всю компанию.

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

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

3 - 4 - 4.7.
Везде речь, в сущности, об одном и том же - о неких эмпирических решениях, возникающих на основе частного опыта. Очень хочется знать, что это за зверь такой.

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

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

Так вот, решение принятое на основании собственного опыта менеджера, а не формальных правил и есть такой зверь :-))

Осталось оценить соотношение типовых и уникальных ситуаций, требующих решения данного менеджера. Осмелюсь утверждать, что области человеческой деятельности, где каждая ситуация требует уникального решения, можно считать по по пальцам. Может быть, мы вообще говорим о разных проблемах? Я, например, о постановке регулярного менеджмента, а Вы - о создании и поддержании Corporate Knowledge Base? Только, извините за ехидство, Ваша проблематика становится актуальной, если Вы разобрались с моей. Так ли это?

Согласен с Сереем по составу и последовательности шагов в схеме "правильного" BPR.

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

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

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

Так и с предприятиями!!!

Александр!

Все правильно. Объединять технологии придется, хотя мне не понятно, при чем здесь ON-LINE?

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

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

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

Цели бывают глобальные - миссия, например, или локальными - продать Васе Пупкину 6000 тонн болотной грязи.

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

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

Кстати, Вы не могли бы дать пояснение смыслу слова "платформа", в котором Вы его применяете?

>>> ...необходим механизм, автоматически приводящий к формализации и целей и способов их достижений.

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

>>> ... дать пояснение смыслу слова "платформа"

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

Константин,

ON-LINE - это из моей первой реплики.

Если online - это система обратных связей, тогда понятно. Хотя, по моему, термин имеет другое значение.

В контексте Сергей Х.-Б. термин On-Line иллюстрировал идею цельности управления (непрерывности цикла.