Category: мода

2019

"Рассказать про данные"

Время от времени (последний раз -- буквально вчера) меня просят где-то публично "рассказать про данные", ибо "больно уж тема на слуху". Что, что мне рассказывать?! Для меня "про данные" -- это:
-- маркетинговый трёп про «дайте нам ваши данные, мы дадим вам бизнес-советы» (это собирается под словом-зонтиком BigData). В узком смысле тут можно дойти до конкретных алгоритмов shallow learning (а вот deep learning "про данные" специально не жужжит, хотя нельзя сказать, что данные там не поминаются. Поминаются, но «не на слуху», на уровень обывателей не выходит). Ещё тут можно говорить про DataFrames, но это уж совсем узко.
-- интеграция данных в промышленных масштабах (мастер-данные, стандарты качества данных, нормативно-справочная информация, управление инженерной документацией, управление конфигурацией и т.д.). Я много лет об этом писал, повторяться не буду -- все эти PLM и ISO 15926. Боком тут -- что происходит с базами данных: все эти NoSQL, трипл-сторы и прочие нереляционности.
-- иногда под "данными" понимают разнообразную визуализацию данных -- научную или даже "инфографику". Так сказать, современная каллиграфия: если есть, что сказать (данные), то нужно сказать максимально кратко, доходчиво, выразительно.
-- отсутствие «данных» в учебных курсах, алгоритмика там есть, а вот работы с данными нет. По этой линии легко прийти к онтологиям (ибо computational ontology -- это про модели данных). Тренд на работу со всё более и более содержательно кучерявыми данными всё более и более простыми алгоритмами.
-- социальные сети, как "общая помойка всего", и способы разгребания мировой помойки. Персональные данные и прайвеси, цифровые следы и скоринговые агентства. Раскрытие информации государства.
-- … и так далее.

А вот про алгоритмы никто не просит рассказать. Они уже вышли из моды, или ещё в моду не вошли? Слово-то "данные" тоже давно используется, но никогда оно не было модным, не просили рассказать о них людям. А "алгоритмы"? Типа как "были бы данные, а алгоритмы найдутся". Нет, не найдутся. Deep learning -- это ведь прежде всего алгоритмы, хотя в какой-то мере и другие типы данных тоже (распределённые представления -- это ведь тоже про данные! Но вряд ли просящие "рассказать про данные" имеют ввиду распределённые представления).
2019

Многоступенчатая объективация и объективизация: от философской логики до системой инженерии

По итогам вчерашнего дня на методологической школе (все материалы школы -- http://goo.gl/nl8Um0) я добавил пару слайдов в презентацию (последними -- http://www.slideshare.net/ailev/ss-38128372), и фактически в докладе рассказал главным образом только их (кому невтерпёж, звук доклада тут: http://goo.gl/M058oJ). Материал этот относительно новый, и я его пока нигде особо не рассказывал. С другой стороны, "узок круг этих революционеров, страшно далеки они от народа". В докладе проясняется цепочка профессиональных позиций в разделении труда, которое обслуживает многоуровневую объективацию:
  • Философские логики – знаковые системы и их связь с окружающим миром, предельные онтологи

  • Рефлексирующие модельеры данных – MOF, Part 2 (Upper ontology, foundational ontology). Компьютерщики: преобразования одних выражений мысли в другие (теоркатегорное представление выходит на передний план, не теория множеств – операции главные, вычисление)

  • Модельеры данных/intermediate ontology – одна логика, помогают выразить мысль непротиворечиво (теоретико-множественное представление – объекты главные).

  • Ситуационные инженеры методов, кейс менеджмент, BPM, проектные управленцы, оргдизайнеры – мысли о деятельности

  • Рефлексирующие инженеры/микротеоретики=онтики – мысли о своей дисциплине (объекты-предметы: системная инженерия, программная инженерия, инженерия предприятия, инженерия психика)

  • Профессионалы-инженеры – мысли о своих конкретных целевых объектах (софтинках, самолётиках) и обеспечивающих объектах (то бишь субъектах).
Это модульная диаграмма (лениво было делать "таблицу" с уровнями -- и так ведь всё понятно!) системы деятельности по объективации, ибо я на лекции демонстрировал мощь системноинженерного мышления для не слишком стандартной системы -- демонстрировал "подход". Конечно, эта диаграмма уровней бессмысленна сама по себе, но позволяет обсудить интерфейсы и их стандарты, разделение труда и закон Конвея -- что ещё обсуждают на модульных диаграммах? Как работает сама эта объективация, конечно, должно обсуждаться на принципиальной схеме, а её я не трогал. И архитектуру не трогал (как я совмещал эту непредъявленную принципиальную схему с предъявленной модульной). И требования не обсуждал -- хотят на этой методологической школе объективацию как целевую систему, вот вам ;-)

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

Доклад "Процессы, проекты, кейсы, практики и прочие описания деятельности"

Доложился сегодня на 2й конференции "Процессное управление сегодня и завтра" (http://www.businessstudio.ru/conference/2013/program/). Мне казалось, что я рассказываю про "процессное управление сегодня", но мне организаторы пояснили, что это остальные доклады "про сегодня", а вот мой доклад как раз "про завтра". Ну-ну, все мы живём на одном глобусе, но "здесь и сейчас" в разные времена.

Вот слайды (http://www.slideshare.net/ailev/ss-28529665):


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

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

Фейсбук -- лидер в поддержке гламурного мышления

Редко, но я заглядываю в фейсбук (куда транслируется мой ЖЖ). Первое, что я увидел сегодня в тамошней ленте -- это запись, сгенерированную по формату "X likes that Y liked R". Важным событием стало уже не то, что понравилось кому-то, а то, что им понравился факт нравленья чего-то другим.

Почему-то вспоминается "Гламурное Кисо, и вообще человек гламурного мышления есть существо, которое считает акты потребления — достижениями" (http://krylov.livejournal.com/1404527.html). Пожалуй, фейсбук с его лайком-на-лайк окончательно закрепился как главная на планете информационная система поддержки гламурного мышления. Кто-то что-то потребил и задокументировал это, другой это лайнул, признав достижением, третий лайкнул то, что второй оценил это как достижение...
2019

Семантический каталог (компонент) методов и софт для его использования

Семантический каталог (компонент) методов -- по аналогии с каталогами комплектующих/предметов снабжения для промышленного оборудования -- представляет собой структурированное в соответствии с метамоделью ISO 24744 описание набора связанных между собой компонент методов набора каких-то дисциплин, выполненное в формате RDL ISO 15926 (поэтому семантический -- в смысле "его информация понятна компьютеру"). Больше всего по содержанию это может быть похоже на http://opfro.org, основные различия в формате, подразумевающем не столько "чтение человеком", сколько доступ со стороны других приложений.

Не вдаваясь в технические подробности, приведем тут ряд сценариев использования такого каталога в формате RDL:
1. Методологи, изучающие методы какой-то дисциплины (например, дисциплины системной инженерии), пользуясь Верстаком (method workbench), коллаборативно пополняют набор компонент методов этой дисциплины, связывает шаблоны работы с шаблонами возможных продуктов работ и делает прочие операции, приводящие к созданию актуализированного набора компонент методов.
Для этого сценария нужно реализовать софт Верстака.

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

3. Основной сценарий, предлагаемый сторонниками ситуационной инженерии методов: используя Составитель (Method Composer), отбираются компоненты метода для конкретного проекта. А потом уже данный "метод проекта" публикуется для сценария 2 -- чтобы быть справочником по методу для всех участников проекта.
Для этого сценария нужно реализовать софт Составителя.
Но я не думаю, что этот сценарий главный. Представьте, что у вас есть толстый учебник "Системная инженерия", из которого вам нужно вырвать ненужные страницы для того, чтобы остаток раздать вашим работникам в качестве руководства к действию. Страницы-то вырвать можно, а с мыслями там что делать? Что-то такой вариант меня не греет (хотя и используется в больших компаниях для постановки "процессного управления", плодя варианты RUP на EPF Composer).
Пусть весь мир идет этим путем, мы не будем этим заморачиваться. Это путь в тупик, в порождение толстых пачек "описания процессов" без малейшей связи с производственной реальностью (хотя я охотно верю, что где-то есть Очень Дисциплинированные Исполнители, которые могут в военно-приказном порядке все это использовать на деле -- но мне даже неинтересно в этом направлении работать).

4. Инженеры, которым нужно выполнить некоторый проект, используют Читальню из сценария 2, но в режиме "активного эссе" (http://ailev.livejournal.com/466004.html, и чуть более развернуто в http://ailev.livejournal.com/810126.html). Это означает, что все ВидыМоделей-из-Читальни работоспособны и могут порождать конкретные модели. Тем самым речь идет не столько о Читальне, сколько о Писальне -- это уже не столько Читальня Учебников, сколько Библиотека Рабочих Тетрадей с Хелпами к ним. Если компонента метода описывает какой-то ВидМоделей, то инженеру-пользователю можно породить экземпляр этой модели и работать с этим экземпляром. Рабочая Тетрадь при этом подтягивает Справочные Данные из RDL (как типографская Рабочая Тетрадь, в которой что-то уже преднапечатано в типографии), а данные моделирования оставляет при себе (как вписывание ручкой в типографскую Рабочую Тетрадь).
И верстать/составлять нужно не "компоненты метода", а экземпляры используемых моделей, оставляя связанные с ними компоненты метода в качестве Хелпа (еще раз напомню про http://ailev.livejournal.com/810126.html)!
Про workflow/lifecycle/project, который ведет инженера через заполнение этой Рабочей Тетради я пока молчу, это мне представляется не главным. Как правильно заметил Cesar Gonzales-Perez, пул продуктов важнее, и софт нужно организовывать вокруг поддержки него, а не поддержки воркфлоу. Как будет устроен тамошний issue tracker можно будет понять позднее).
Для этого нужно реализовать софт Писальни -- Рабочей Тетради Модельера/Инженера/Организатора (инженера -- если модели "железной" системы; организатора, если речь идет об организационной модели).

Итого: нужно делать Каталог-RDL (невидимый простым человечьим глазом, а видимый только как endpoint из semantic web), Верстак, публичную Читальню и затем коллаборативную Писальню (Рабочую тетрадь модельера).
2019

Модель интеллектуальной обработки: ускорители в ассортименте. Вероятностный сопроцессор на подходе.

Моя модель интеллектуальной обработки сводится к разнообразию используемых обработок знаний (и тем самым применяемых в этих обработках спецпроцессоров -- ровно как в мозге довольно много разных "зон" с их специализацией), но в целом я бы выделил три основных работы (давно об этом думаю, вот, например, переписка июля 2003г. http://community.livejournal.com/openmeta/24040.html, но тут я добавлю куски):
1. Вероятностная работа со "смыслами" (контекст-анализ), определяющая предметную область в достаточной мере, чтобы разобраться с омонимами и вообще речью. Распознавание образов тоже сюда относится: отнесение каких-то "образов" к смыслам.
2. Эвристичные логические алгоритмы для высокопорядковых логик в рамках контекста/микротеории, найденной в пункте. Понятное дело, из-за NP-характера (запредельная вычислительная сложность) задачи эти все решения являются "вероятными", и не факт, что здесь тоже не будут работать вероятностные алгоритмы, связанные с "распознаванием образов". Cyc, например, решает такие задачи введением марковской логики (где логические высказывания снабжаются вероятностями их истинности).
3. Собственно "логика", подразумевающая "точное решение" (например, SAT). Но это совсем специальный случай, а не самый частый. Это только недоразумение, что компьютеры ассоциирууются сегодня только с этими алгоритмами.
4. А еще должны быть симуляционные модели, которые воспроизводят какие-то сложные куски реальности (можно думать о какой-нибудь Моделике).
5. И так далее...

Современные исследования тоже где-то в этом русле (например, поглядите на работы последних лет от Cyc: http://cyc.com/cyc/technology/pubs, или вспомните тот же пакет по работе с натуральными текстами Apache UIMA http://uima.apache.org/). Прорывы в софте налицо: одни и те же данные молотят самыми разными методами -- сочетая вероятностные расчеты и строгий логический вывод, а часто еще и численное моделирование в рамках одной задачи.

Но главное, намечается существенный прорыв в аппаратуре. Когда-то думали, что пролог-машины или лисп-машины решат все задачи AI, но теперь очевидно, что этого недостаточно. Нужны обильные вероятностные расчеты, и поэтому процессорные ускорители должны быть не только "логическими", но и "вероятностными". И вот оно -- готовятся к выпуску (скоро, в 2013 году) аппаратные ускорители x1000 для вероятностных алгоритмов: http://www.hpcwire.com/features/Startup-Aims-to-Shake-Up-Computing-with-Probability-Processing-100816474.html?viewAll=y

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

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

Модные организационные паттерны. Праксиологические организационные паттерны. ПраксОС.

Про теорию моды в приложении к праксиологии в целом и management fashions в частности можно читать в Management Fashions: Turning Bestselling Ideas Into Objects and Institutionsby Krzysztof Klincewicz или кратенькой статье Theories of (management?) fashion: The contributions of Veblen, Simmel, Blumer, and Bourdieu -- by Charles-Clemens Ruling (http://www.hec.unige.ch/recherches_publications/cahiers/2000/2000.01.pdf). Материала на эту тему полно с середины 90-х годов, когда тему поднял Eric Abramson (см. "mamagement fashions" в Гугле).

В современной социологической теории мода рассматривается не как экономический феномен (в котором типичное рассуждение о том, как злобные поставщики товаров и услуг изобретают новые моды, чтобы продать одним и тем же людям множество товаров взамен ранее проданных ими же, но уже немодных), а как пары способов -- 1. изменения общества и 2. воспроизводства структур общества. Слово "мода" тут такое же, как "бунт": как известно, закончившейся удачей бунт таковым не называют; так и "модой" называют только такие изменения, которые не воспринимаются как пришедшие навечно. Но уж в силу самой природы жизни все новое быстро распространяющееся так же быстро сменяется еще более новым -- и поэтому подход к анализу распространения тех или иных best practices с точки зрения теорий моды вполне оправдан. Быть модным -- это показывать близкое знакомство с наиболее свежем выражение современности. Неудивительно, что организаторы хотят быть модными в плане внедряемых ими подходов -- они просто демонстрируют свое знакомство с вопросом, погруженность в современное состояние. Так, сегодня немодно говорить про "управление" (management), но модно говорить про лидерство (leadership) -- и вот уже повсеместно у нас не управленцы, а лидеры. Ничего не изменилось, но акценты в такой риторике проставлены уже по-другому -- а через некоторое время эти акценты становятся обыденностью, и тогда нужно ждать чего-то новенького.

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

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

Поэтому от языка "теорий" нужно перейти к языку паттернов -- много более стабильному языку, в котором обсуждается суть в рамках заданного однажды дискурса, а не бултыхание в волнах приходящих и уходящих модных словес. Так, "поиск противоречия" как главная часть эффективно устроенного мыслительного процесса есть и у СМД-методологов (в 1986 году Г.П.Щедровицкий втолковывал участникам ОДИ, на которой я имел честь быть: "не сформулировал противоречие -- не будет решения"), в ТРИЗ (где нахождение противоречия крайне обязательно), в thinking process (под нелепым названием "грозовая туча" -- можно обсуждать, зачем потребовалось вводить такое странное имя). Конечно, есть различные особенности в каждом из этих подходов, но паттерн один и тот же: "если ищешь какое-то решение, то найди в ситуации противоречие (два одновременно истинных противоположных высказывания про проблемный объект), а затем найди точку зрения, с которой этого противоречия не существует. Это и будет решением проблемы". Если ты видишь этот общий паттерн -- то тебе не нужно лихорадочно менять ТРИЗ на голдратовщину или альтшуллеровщину на TOC. Можно просто использовать паттерн, с адептами каждой из мод говоря на их языке.

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

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

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

P.S. Ага, я знаю про спекуляции о "праксиология — философская теория деятельности, нацеленная на должное бытие, противостоящее сущему бытию". И знаю про Котарбинького, и про фон Мизеса тоже знаю. И про праксЕология/праксИология (и praxEology/praxIology) тоже знаю. Считайте, что мы от них всех равноудалены (или, что то же самое -- равноприближены).
2019

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

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

Как я сообщил в длинном тексте "Управление организационными паттернами" http://ailev.livejournal.com/488174.html, нужно попытаться использовать культурную форму системы организационных паттернов в скрещении с сегодняшней модой управления идеями. Получаем управление организационными паттернам (чтобы хоть как-то отслюнявиться от управления продуктовыми инновациями и идеями по новым видам продуктов, которые тоже проходят по ведомству управления идеями).

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

Современный модный софт на эту тему -- idea management или innovation process management (см. http://www.innovationtools.com/resources/ideamanagement.asp). Примеры -- idea management софт http://www.ovoinnovation.com/. Или innovation management suit http://www.brightidea.com с фокусом на idea management. Или http://www.imaginatik.com/ про то же самое. Свойства этого софта уже существенно отличаются от wiki:
-- помощь в организации синхронных итеративных бреймстормингов (напоминалки участникам, ведение списков участников и т.д., т.е. типовая поддержка всего workflow созыва совещания).
-- работа с идеетворческими компетенциями сотрудников (при ранжировании идей -- оценивается, при приглашении на брейнстормы -- используется)
-- какой-то вариант коллаборативного outliner/mindmap для capture и restructuring идей,
-- механизм межидейной связи (гипермэп? гипераутлайн?)
-- встроенные системы оценки и голосовалки по вариантам идей (ранжирование идей -- проблема в том, чтобы слабые идеи не отваливались слишком рано, а сильных идей было не слишком много).
-- механизм указания авторства, подписок на обновления отдельных идей, закрытые только для группы материалы, дискуссии и прочее из арсенала social web.
-- issue tracker по порождаемым проектам внедрения. Включая оценку финансов, связанную с внедрением. Особая гордость -- интеграция idea management с project tracking (еще одно название для issue tracking).
-- поддержка мотивации: вознаграждения и почёт.
-- аналитика (метрики) по общему процессу и архив с хорошим поиском.
-- интеграция в разные корпоративные справочники, интеграция с офисными приложениями. Обеспечение доступа за пределами фирмы (клиенты, поставщики, внешние эксперты за фаерволом). Доступ с мобильных устройств.

Реализация -- как правило, hosted services. Каждая компания хвастается, что в софт зашиты наилучшие организационные паттерны для извлечения идей, ранжирования идей, награждения сотрудников за лучшие идеи и т.д. Использовать софт предлагается в marketing and branding, new product development, process improvements, cost reduction initiatives, human resources programs, internal communications.

Кроме idea management общего вида затесываются и специализированные продукты типа Goldfire Innovator (http://www.invention-machine.com/prodserv/GFIN.cfm) -- поддержка творческого процесса ТРИЗ, включая такую традиционную для ТРИЗ вещь, как базу патентов с семантическим поиском в ней. Это, конечно, крутая экспертная система на тему оформления инженерной интуиции, но как-то выбивается из общего ряда однотипного софта.

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

Управление идеями

Бизнес-идей уже так много, что на свет появилось словосочетание idea management. Бизнес-мода -- это мода на конкретную бизнес-идею. Вот, например, график упоминаний TQM (отчетливо видно, что это была примерно десятилетняя мода с пиком в 1993г.):

(http://www.careerjournal.com/columnists/theorypractice/20060627-theorypractice.html -- тут в частности говорится и о том, что это раньше мода на конкретную идею была примерно десятилетней, сейчас мода идет примерно три года).

Впрочем, сам термин "управление идеями" тоже похож на быстро проходящую моду:


В 2003г. вышла интересная книжка Давенпорта, автора такой (старо)модной идеи, как business re-ingeneering -- Thomas H.Davenport, Laurence Prusak, "What's the Big Idea?: Creating and Capitalizing in the Best Management Thinking" (http://books.google.com/books?id=0IK7fbSd-7IC&dq=what%27s+big+idea). В книжке есть приложение с примерно полутора сотнями бизнес-идей (число тут трудно оценить: сами авторы приводят пример с TQM и Шесть Сигма -- некоторые исследователи считают, что это одно и то же, а некоторые говорят о том, что это разные идеи).

В книжке приводится интересная классификация идей по целям их применения на "делать правильно", "делать правильное" и "делать что-то новое" (improved efficiency, greater effectiveness, and innovation in products or processes. Или doing things right, doing the right thing, and doing something new). Понятно, что самые интересные идеи пытаются достичь всех трех целей, но огромное их количество нацелено на что-то одно. Вот пример (табличка 3-1) из книжки:
Efficiency -- activity-based costing, activity value analysis, benchmarking, centralization, cost-benefit analisys, downsizing, EVA, economies of scale, enterprise systems, experience curves

Effectiveness -- artificial intelligence, attention management, balanced scorecard, brand management, business modelling, change management, core competence, core capabilities, corporate culture, customet relationship management, decentralization, decision trees

Innovation -- adaptive enterprises, brainstorming, chaos/complexity, concurrent engineering, creative destruction, diversification, double-loop learning, empowerment, enrepreneurship

Жизненный цикл идеи бывает внутренний (вхождение в моду внутри конкретной организации) и внешний (пресса, консультанты, наука, разные организации и т.д.). P Cycle -- это прохождение идеи через стадии pilot, project, program, perspective, pervasiveness. Проблема в том, чтобы организация восприняла правильную идею (а их -- тьмы, тьмы, и тьмы) в правильное для себя время (ибо организации часто меняются со скоростью большей, нежели какая-то идея может систематически овладеть организацией). К каждой идее должен прилагаться "бизнес-гуру", приделывающий к идее ноги. Без гуру (guru, leader, idea practitioner) идеи остаются мертвы.

Cписок бизнес-идей (приложение А):
Collapse )
Это совсем-совсем неполный список. В него не вошли такие популярные сегодня (да и раньше) идеи, как
Beyond budgeting
Corporate life cycles
Enterprise asset management
Enterprise architecture
Flow
Management functions
SPIN/теория больших продаж
Talent management
Theory of constraints
Virus marketing
и многие многие другие.

А теперь несколько исходящих из этого идейного изобилия моих суперкратких тезисов (из обновленной программы сдвинутого с этих выходных по совокупности разнородных технических накладок семинара "Организация деятельности в 21 веке"):

1. Огромное количество этих идей противоречивы, говорят об одном и том же на разных языках, приходят к противоположным выводам, имеются в жутко искаженных "попсовых" вариантах. Непрерывно идет дождь из новых идей, их скорее переизбыток, нежели недостаток. Пользоваться этими идеями нельзя, если специальным образом не выбирать совместимые наборы идей в форме той или иной бизнес-философии. Для этого многие из этих идей нужно декомпозировать до каких-то "протоидей" и выразить в общем языке этих "протоидей", чтобы быть уверенным в совместимости. Я бы тут сослался на Accretion Model of Theory Formation (в конце постинга http://ailev.livejournal.com/469995.html), согласно которой время от времени нужно менять репрезентацию для накопленных эвристик, тем самым "уплотняя" излишне разлапистые знания. Поэтому нужны еще идеи по поводу бизнес-идей (типа идеи "управления идеями", ideas management).

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

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

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

5. В 21 веке для каждой такой бизнес-философии должен быть поддерживающий ее софт (насколько я понимаю, впервые это было заявлено в идее бизнес-реинжиниринга, но в идеях 21 века уже стало общим местом). Увы, сегодняшний бизнес-софт в силу наличия идейного изобилия существенно клочковат, ибо в его основе лежат не бизнес-философии (совместимые наборы идей), а отдельные часто несовместимые между собой идеи. Софт важен и потому, что он являет собой учебную программу (ИКТ играют две роли -- enabling для новых техник работы и enabling в плане внедрения/обучения новым техникам работы). Естественная модульность такого софта -- это поддержка тех или иных бизнес-идей. С учетом этого существующая "модульность приложений" идет лесом, и на первый план выходят какие-то другие принципы создания софта (от аспектного и контекстного программирования до паблишинг-метафоры пользовательского интерфейса для решения бизнес-задач).
2019

Гламура и дискурса

Однако, пелевинские гламура и дискурса очень гламурно дискурсны для обсуждения всяких комьюнити. Попробовал вчера порассуждать в этих терминах про Свободный Кабинет (sk_ru), и мне понравилось.
Надо признаться, что в то время я был бойким, но невежественным юношей и неверно понимал смысл многих слов, которые, как мне казалось, знал. Я много раз слышал термины «гламур» и «дискурс», но представлял их значение смутно: считал, что «дискурс» – это что-то умное и непонятное, а «гламур» – что-то шикарное и дорогое. Еще эти слова казались мне похожими на названия тюремных карточных игр. Как выяснилось, последнее было довольно близко к истине.
Когда процедура знакомства была завершена, Бальдр сказал:
- Гламур и дискурс - это два главных искусства, в которых должен совершенствоваться вампир. Их сущностью является маскировка и контроль - и, как следствие, власть. Умеешь ли ты маскироваться и контролировать? Умеешь ли ты властвовать?
Ну, власть меня не интересует. Но во влиянии время от времени заинтересован. ГламурА и дискурсА для этого -- самое оно. Чисто на дискурсАх влияние не берется, нужны еще гламурА. Почему?
- Потому что гламур и дискурс - на самом деле одно и то же, - сказал Бальдр.
- Да, - согласился Иегова. - Это два столпа современной культуры, которые смыкаются в арку высоко над нашими головами.

http://slil.ru/23242606