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

Фактически речь идет о двух способах решения задач:

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

Какое-то мутноватое получается объяснение, не так ли? Добавляет путаницы то, что английские “template” и “pattern” зачастую оба переводят как “шаблон”, и смысл при этом частично теряется.

Думая о том, как это можно объяснить “на пальцах”, нашел аналогию в шахматах:

• Дебюты из шахматных учебников - это шаблоны: учи и разыгрывай, в учебнике все расписано от стартовой позиции и на 20 ходов вперед.
• Типовые комбинации миттельшпиля - это паттерны. Например, “вилка” - это паттерн: увидел в позиции возможность ее сделать - делай, или угрожай, что сделаешь. Сдвоенные по вертикали ладьи - это паттерн, а сдвоенные пешки - это антипаттерн: если есть возможность, старайся избегать таких позиций. Но в учебнике нет и не может быть инструкции как, начав партию, сделать противнику вилку.

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

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

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

Паттерны в BPM - это типовые фрагменты процессов или межпроцессного взаимодействия (некоторые примеры).

Уместно спросить: от чего больше пользы? Мое мнение - от паттернов:

• Шаблоны специфичны (один процесс - один шаблон), паттерны универсальны. Хороший паттерн можно использовать в самых разных бизнес-процессах независимо от отраслевой специфики.
• Польза от шаблона на практике оказывается меньше ожидаемой. Как правило, позаимствовать удается только магистральный путь (happy path), а дьявол оказывается в деталях - в обходных путях, в обработке нештатных ситуаций.
• Эффект от использования правильного паттерна может быть очень большим. Например, в нашей практике был случай, когда процесс, изображенный на 6 склеенных друг с другом листах формата А4, за счет использования правильного паттерна удалось свести к изящной конструкции из 15 процессных шагов.
• Что касается антипаттерна, его польза в том, что в нужный момент он предостережет вас от ошибки. Цена ошибки теоретически может быть любой, и иногда реально большой.

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

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

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

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

В самом деле, представим себе бизнес-процессы, составляющие типовую цепочку создания ценностей компании:

1. от идеи до продукта
2. от продукта до обращения
3. от обращения до заказа
4. от заказа до оплаты
5. после продажи

Точно так же, как прочность цепи определяется прочностью одного самого слабого звена, производительность компании зачастую определяется производительностью “бутылочного горлышка” - наименее эффективного процесса (”ограничения” в терминах Теории ограничений Голдратта). Повышение производительности ограничения, скажем, на 10% повлечет повышение показателей компании примерно на те же 10%. Повышение же производительности остальных процессов в рамках модели “цепочки” не дает ничего. Отсюда следует экстремальная важность выбора правильной точки приложения для BPM-инициатив.

В современной экономике ограничителем, как правило, является рынок. Но в чем именно он нас ограничивает - в интенсивности первичных обращений (п.2)? Или может в нашей способности доводить обращение до заказа (п.3)? А может нам стоит обратить особое внимание на послепродажные процессы (п.5)? Ведь можно прекрасно отработать “на отлично” в рамках процесса продажи (п.4), но потерять и этого, и еще 10 потенциальных клиентов, потому что не отработан процесс работы с рекламациями.

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

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

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

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

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

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

А толчком к выводу в начале этой заметки - активнее продвигать изложенные идеи - стали опубликованные тезисы доклада аналитика Гартнер Билла Россера “Gartner Identifies Seven Major Guidelines to BPM Project Success” к предстоящей конференции по BPM (русский перевод на BPMS.ru). Цитирую:

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

Золотые слова!

(Эта заметка развивает предложенную концепцию стэка управленческих компетенций.)

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

BPM позволяет справиться с этой проблемой за счет:

1. непосредственно исполняемых схем бизнес-процессов (”What You See Is What You Run”)
2. быстрого прототипирования и коротких циклов разработки

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

То есть ИТ-консультанты пытаются повторять мантры, услышанные от бизнес-консультантов, типа: “SOA-решения от компании XYZ повышают мобильность и конкурентоспособность бизнеса!” Но это производит впечатление только на представителей ИТ-службы заказчика. У людей же бизнеса подобные пассажи вызывают в лучшем случае недоумение, а зачастую - резкое отторжение.

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

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

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

Короче, первые знают “зачем”, но слабо представляют себе “как”, вторые - наоборот. Хотя бизнес-консультанты в массе хорошо представляют себе что такое бизнес-процессы и признают их роль в трансформации бизнеса, они слабо представляют себе что такое BPM и чего от него можно ожидать. Заказчику самостоятельно связать одно с другим непросто и конечно, он предпочел бы, чтобы между консультантами, работающими на уровне бизнес- и BPM-консалтинга, было бы взаимопонимание.

Может быть, консультанту по BPM просто освоить смежную область, стать по совместительству бизнес-консультантом и таким способом закрыть проблему? Эту идею следует отвергнуть:

• Консультанту по BPM определенно полезно разбираться в смежной области. Например, мы в проектах BPM используем концепцию цепочки создания ценности и принципы Теории ограничений. Но использовать и разбираться на уровне консультанта - это разные вещи. Ценится ведь бизнес-консультант не только досконально разбирающийся в той или иной концепции, но и обладающий кругозором, позволяющий ему определить какая концепция показана данному конкретному заказчику. Дотянуться до этого уровня консультанту по BPM нереально.
• К тому же не будем забывать, что помимо собственной области управления бизнес-процессами, консультант по BPM обязан разбираться в смежных областях ИТ - BPMS, бизнес-правила, SOA, интернет-технологии, корпоративная архитектура, разработка баз данных и бизнес-приложений.
• Даже если найдется такой супер-консультант, который разбирается и в BPM, и в ИТ, и в бизнес-концепциях, то как отнесется к нему потенциальный заказчик? По моим наблюдениям, к таким супер-специалистам заказчики относятся с недоверием - интуитивно они подозревают, что если его знания так широки, то они не могут быть глубоки. То есть его таланты и труд не будут оценены по достоинству.

Существует также разрыв между BPM-консалтингом и ИТ-консалтингом. Досадно, но факт: до ИТ-специалистов и даже до ИТ-руководителей идеи BPM зачастую доходят медленнее, чем до руководителей компаний и вообще людей бизнеса.

Бессмысленно сетовать на разрыв между бизнесом и ИТ до тех пор, пока мы не преодолели разрыв на уровне консалтинга!

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

Определенные подвижки в этом направлении видны: например, интерес к конференциям по BPM только растет. Бизнес- и ИТ-консультанты, которые на них приходят, получают представление о том, что можно получить от BPM и от специалистов по BPM.

• Слабое место бизнес-консалтинга - практическая реализация концепций. А это как раз то, в чем мы - специалисты по BPM - имеем опыт и готовы помочь.
• ИТ, располагающийся на нижних этажах стэка компетенций, сталкивается с обратной проблемой обоснования целесообразности инфраструктурных проектов. Бизнесу не нужны ERP и SOA сами по себе, ему нужны предсказуемо и без сбоев работающие бизнес-процессы. BPM логически связывает одно с другим, поэтому и здесь есть отличный потенциал для сотрудничества.

(Эта заметка развивает предложенную концепцию стэка управленческих компетенций.)

Общая черта управленческих методологий: в каждой подчеркивается необходимость вовлечения в проект первого лица компании и накопления собственной компетенции.

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

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

Как решить - что развивать самим, а что брать со стороны? Предлагаю руководствоваться “правилом шашечной компетенции”: в изображенной выше матрице корпоративных компетенций ячейки заемной компетенции должны граничить с ячейками собственной компетенции, а не друг с другом.

Например, вот так:

Или так:

Но, желательно, не так:

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

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

(Эта заметка развивает предложенную концепцию стэка управленческих компетенций.)

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

Рассмотрим в качестве примера концепцию клиенто-ориентированности:

• она присутствует в TQM (качество как соответствие ожиданиям клиента)
• она присутствует в реинжиниринге (радикальное усовершенствование бизнес-процесса, понимаемого как последовательность действий, дающих на выходе ценный с точки зрения клиента результат)
• она присутствует в методологии Раммлера-Брахе, системе Тойоты и Lean (цепочка создания ценности для клиента)
• и при этом сейчас появляется новая концепция Outside-In, в которой в очередной раз утверждается примат клиенто-ориентированности

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

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

То есть что происходит:

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

Получается, важнее кто делает, а не то, как это называется.

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

(Эта заметка развивает предложенную концепцию стэка управленческих компетенций.)

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

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

Например, EPM (Enterprise Performance Management), BI (Business Intelligence) и BSC (Balanced Score Card) - это все полезные вещи, но они дают только канал обратной связи. Для сравнения, BPM дает каналы и прямой, и обратной связи - роль последнего выполняет BAM (Business Activity Monitoring).

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

BI и BSC - это всего лишь панель приборов; чтобы заставить компанию совершить маневр, вам необходим BPM. С другой стороны, BPM относится ко второму, а BSC - к третьему уровню стэка. Поэтому комбинация BPM/BAM и BSC должна быть неплохой идеей.

(Эта заметка развивает предложенную концепцию стэка управленческих компетенций.)

В свое время я обратил внимание на то, что о бизнес-процессе и процессном подходе так или иначе говорится в методологиях TQM, Lean, Шесть сигм. В книгах по Six Sigma или Lean можно обнаружить целые разделы, в которых фактически пересказываются базовые принципы проектного управления и/или BPM. О процессах также любят порассуждать поставщики систем ERP и CRM.

Но практика уже многократно доказала, что бизнес-процессы - предмет слишком серьезный для того, чтобы заниматься им факультативно. Управление бизнес-процессами составляет отдельную дисциплину под названием BPM, и попытка “заодно” разобраться с бизнес-процесса в рамках реализации более глобальной управленческой концепции ни к чему хорошему не приводит. Было бы лучше, если бы управленческие методологии и корпоративные системы рассматривали бизнес-процессы не как часть собственного предложения, а как смежную дисциплину. Поставщикам корпоративных систем хотелось бы дополнительно пожелать добиться большей открытости их функционала для внешних BPMS.

Оборотная сторона этого тезиса - BPM не нужна собственная методология!

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

Ведь кому-то ближе философия Lean, кому-то - Теория ограничений, а кто-то заявляет, что это все устарело, и пропагандирует Outside-In. И очень хорошо - BPM подходит к любой из них, для любой из них он может сыграть роль “приводного ремня”.

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

Пока собрался попросить у Гугла приглашение, пока они его прислали (месяца два пришлось ждать), пока нашлось свободное время разобраться и поэкспериментировать… в результате только сейчас дозрел поделиться впечатлениями.

Начну с резюме: полезная вещь, жалею что раньше не включился.

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

• О сервисе
• Где использовать

Цитирую: “Google Wave - это онлайновое средство коммуникации и совместной работы в реальном времени”. Понятно? Мне лично ни черта. Поэтому расскажу на что это похоже, отталкиваясь от привычных вещей. Google Wave состоит… гм… из Waves. Буду называть их “гугл-волнами” или просто волнами. Сам сервис, чтобы не путаться, буду называть “GW”.

Итак, что такое гугл-волна? Представьте себе текст MS Word. Теперь представьте, что:

• Он хранится на сервере Гугл и вы обращаетесь к нему из браузера через страничку GW.
• Сильно урезан в части форматирования, но минимально необходимые вещи имеются: шрифты, цвета, поля, заголовки, списки, вставка картинок. Можно прикреплять файлы, как к email.
• В нем постоянно включен режим отслеживания изменений (наглядно видно что, кто и когда менял).
• Насыщен комментариями, вопросами-ответами, обсуждениями. Только не на полях, как в Word, а прямо в тексте блоками, выделенными рамками, и с теми же возможностями форматирования, что и в основном тексте.
• Текст и комментарии создаются, правятся, удаляются любым участником, так что при желании можно все подчистить и получить на выходе аккуратный текст. Но все ходы записываются и есть кнопка replay, показывающее что с документом происходило.
• Участник - это создатель волны и те пользователи GW, кого он пригласил в волну.
• Под реальным временем подразумевается вот что: если кто-то из участников что-то делает с волной, а у вас в это время открыто окно GW, то вы видите как он набирает буковки.
• Совместная работа в самом полном смысле этого слова: запросто я могу вводить текст в один раздел и одновременно другие участники - заполнять свои разделы, и при этом мы будем подбрасывать друг другу комментарии, замечания и вопросы. Никакой блокировки, никаких конфликтов благодаря реальному времени (правда, я не пытался их провоцировать).

Законный вопрос: настолько ли это лучше комбинации MS Word +электронная почта, чтобы осваивать еще одно средство? Полагаю, да. GW избавляет от вопросов типа “где последняя версия документа?” или “внесены ли в него мои последние правки?”. Кейт Свенсон справедливо указывает (тут и тут), что мы все подвержены “наркотической зависимости от email”, и GW - правильное лекарство от этой болезни.

Первые волны, на которых я экспериментировал:

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

С чем еще можно сравнить гугл-волну:

• С дискуссией на форуме. Волна с большим числом комментариев становится на него похожа. Поддерживается иерархия комментариев (комментарии к комментариям). Разница в том, что в любой момент можно отредактировать и основной текст, и любой комментарий.
• С фото-сайтом. Можно опубликовать фотографию в новой волне и обсуждать ее в кругу друзей.
• С хранилищем документов (Document Management System) вообще и с wiki, в частности. Похоже коллективной работой. Непохоже наличием реального времени в GW и тем, что обсуждение ведется не на отдельной страничке, как в wiki, а прямо в тексте. И то, и другое по моему плюс. Простая до тривиальности модель доступа: участник может все, остальные ничего. Отсутствие оглавлений и жесткой классификации, только тэги. Вывод: wiki - для нетленки, волна - для пены дней.
• С багтрекингом. Там тоже есть кейс, к которому цепляются файлы и по которому ведется обсуждение. Непохоже отсутствием в GW какой-бы то ни было структуры - чистый ad-hoc. В багтрекинге же без структуры не обойтись.

Еще плюсы:

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

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

• Нет уведомления об изменениях в ваших волнах. Правда, если страница GW открыта в одной из вкладок браузера, то в заголовке появляется “Google Wave (3)”, что означает, что в волнах, за которыми вы следили, появились три изменения. Но надо постоянно держать страницу открытой. На странице идей народ массово высказывает по этому поводу свое неудовольствие. Есть мнение, что Гугл таким образом хочет “убить” email. Но по-моему, это врядли. Думаю, они реалисты и понимают, что это дополнение, а не замена. Так что надеюсь, в финальной версии возможность уведомления появится. По почте и по RSS. Кстати, мне лично второй вариант нравится больше, ведь страница Google Reader у меня и так постоянно открыта.
• Так же абсолютно необходим постоянный адрес (URL) волны. Пообсуждали-поредактировали, зафиксировали (запретили дальнейшие изменения) и получили HTML-страницу, на которую можно сослаться из письма или из блога. Пока я не вижу, как гугл-волну сделать частью Паутины. А концептуально это очень круто: при помощи GW можно было бы добавить ad-hoc функциональность везде, где ее не хватает. SAP со своим Gravity (BPMN-дизайнер для GW) добился той же цели, но при помощи плагина. Мне кажется, логичнее поступать наоборот: к примеру, вставить ссылку на волну в поле Link задачи MS Project, а не делать из Project плагин GW. <updated>URL волны отображается в адресной строке браузера, когда выбираешь волну. Так просто!</updated>
• Почему-то нет возможности оформить нумерованный список. Мелочь, но странно: маркированный список в панели форматирования есть, а нумерованного нет.
• Самая главная проблема: чтобы все это у вас реально заработало, необходимо, чтобы все те, с кем вы собираетесь общаться или совместно работать, были пользователями GW. Это барьер, и довольно высокий. Для сравнения, чтобы начать пользоваться гугловыми картами, этого не требуется, не говоря уж о поисковике. И чтобы отправить почту через gmail, тоже не требуется чтобы получатель имел почтовый ящик тоже обязательно у гугла. В гугловом фотобанке picasaweb  я могу дать доступ к моему приватному альбому, послав “секретную” ссылку на него по почте. Можно было бы в GW реализовать тот же подход - это даст возможность разово подключить к конкретной волне случайного участника без постоянного аккаунта. Впрочем, уверен, что ребята в гугле что-то придумают в плане облегчения доступа к GW. Не забываем: пока речь идет о версии сервиса для ограниченного тестирования.

Как стать пользователем GW? Для начала, у вас должен быть гугловый почтовый ящик (@gmail.com). Дальше самый простой путь - обратиться к кому-то, у кого уже есть GW. У каждого из нас есть по 25 приглашений. Можно обратиться непосредственно к гуглу, но приготовьтесь к тому, что придется ждать. Не исключено, что за это время гугл сделает сервис общедоступным. Приглашение же от существующего пользователя приходит практически сразу.

<updated>Полезные ссылки:

• Google Wave 101
• The Complete Guide to Google Wave
• Ultimate List of Google Wave Gadgets and Tools
• How to Install a Google Wave Gadget Extension

Happy waving!</updated>

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

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

Так что давайте с пониманием относиться к тому, что пользователи не всегда ведут себя так, как нам бы хотелось.

Бизнес похож на войну, война похожа на шахматы. Конечно любая аналогия хромает, но почему бы не поиграть в аналогии для развлечения?

Бизнесмен: мы принимаем решения на основе предварительной оценки окупаемости или возврата на инвестиции (ROI).

Шахматист: конечно надо считать когда и сколько материала - пешек, фигур - ты выиграешь в результате того или иного хода. Мы тоже считаем комбинации. Только у нас партия состоит не из одних комбинаций. Бывают ходы вынужденные, когда думаешь не о том, чтобы побольше съесть чужих пешек и фигур, а о том, чтобы не съели твои. Бывают ходы, улучшающие позицию. Бывает, что жертвуют материалом, чтобы улучшить позицию  - “получить игру”. Ведь если позицию не развивать, то просто не будет возможности развернуть атакующую комбинацию и ни до какого ROI дело вообще не дойдет.

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

Бизнесмен: у нас тоже есть стратегия компании.

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

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

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

Военный: мы тоже считаем темпы операций. Классический пример: время мобилизации и развертывания в начале войны стали краеугольным камнем знаменитого плана Шлиффена немецкого Генштаба на войну, которую потом назвали Первой мировой. Загонять противника “под флажок” мы тоже умеем: наводнить его штабы противоречивой информацией и дезинформации, совершать ходы, которых он не ожидает, чтобы он не успевал переваривать информацию и в результате постараться добиться паралича управления войсками.

Бизнесмен: так, кажется я начинаю понимать что это за business agility, о которой в последнее время столько разговоров…

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