Обсуждение

Нет коментариев, ибо пока всё смутно...

Я как раз по поводу этой смутности и написал исследовательскую программку по 14 пунктам :-)

Возможно, по поводу ACM вам будет интересно пообщаться с Максимом Смирновым (http://mxsmirnov.wordpress.com/)

Может, и интересно: он знает много разного про конкретные приложения, а я знаю много разного про метамодели, которые лежат в их основе. То, что Смирнов говорит в http://mxsmirnov.wordpress.com/2011/08/07/%d1%87%d1%82%d0%be-%d0%be%d1%81%d1%82%d0%b0%d0%bd%d0%b5%d1%82%d1%81%d1%8f-%d0%bf%d0%be%d1%81%d0%bb%d0%b5-acm-%d0%b8-bpms мне глубоко понятно, и даже сами люди в ACM-комьюнити это понимают. Так, они описывают задачу process composer (она же -- case composer) как лежащую сейчас вне сферы нового OMG стандарта по управлению кейсами. Для целей этой композиции они предлагают брать SPEM 2.0 -- то есть цепляют ситуационную инженерию методов. Все эти сферы тесно переплетены, и нужно иметь новое компактное описание. А уж новый софт его поддержит. Фишки ACM по отношению к SME в том, что -- описания ситуационного метода строятся run-time, и формализмы предполагают упор на исполнение, а не на анализ -- последовательности задаются не только и не столько "следованиями", сколько правилами (кстати, про использование машины состояний для этого нужно вспомнить аргументы Конрада Бока времен разработки ISO18629/PSL) Я вот буду получать это новое компактное описание деятельности (и делать софт для его получения) в рамках проектов praxos и dot15926. А в нужный софт мы потом отмэппимся, ибо встроенные средства мэппинга там будут.

Case Based Reasoning -- можно считать смежной темой? Или это ближе к экспертным системам все же (наследником которых считается ACM)?

Нет, исторически эта тема к ACM непричастна. Но за уши притянуть вполне можно (но не нужно).

но несколько перегретая, на мой взгляд. Шуму много, с продуктами пока не очень. У меня тоже есть кое-что на эту тему: http://mainthing.ru/ru/item/401/. Главная мысль: отделять BPM и ACM непродуктивно, так как 1) есть масса промежуточных случаев; 2) процессы могут инициировать кейсы, и наоборот; 3) то что сегодня кажется кейсом завтра запросто может оказаться процессом, и наоборот; 4) есть масса пересекающегося функционала: таск-менеджмент, BAM, бизнес-правила... Поэтому инструмент должен быть единым. А с учетом того, что BPMS все же гораздо более зрелая технология, мой прогноз - через 2-3 года мы увидим функционал ACM в составе передовых BPMS. И тогда заживем :) Кстати, Анатолий, зря не ходите на семинары bpms.ru. Там тема ACM уже неоднократно обсуждалась.

Конечно, и рассказ про них всех, и инструмент должен быть единым. Я бы также добавил сюда до кучи еще три популярные концепции про развертку дел во времени: управление проектами, ситуационную инженерию методов и популярное сейчас в инженерии управление жизненным циклом. Я тут пытаюсь делать некоторые практические шаги в этом направлении (например, см. мои последние постинги в praxos. Что же до семинаром bpms.ru -- так там больше внедрятели BPMS-систем вкупе с ERP и прочими "банковскими днями". А у меня таки другие отраслевые акценты, другие примеры, другие интересы...

Мне кажется, с точки зрения методологии ACM имеет явные параллели с MBO - Management By Objective. Бог с Вами, какие "банковские дни". Это комьюнити, а не маркетинговые мероприятия. Профессионалы собираются в свое личное время поговорить о том, что их интересует. Впрочем, колхоз дело добровольное.

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

I am in favour of the convergence between BPM and ACM to the coordination of activities via different techniques: template-based, event-based, data-based, rule-based, role-based, intelligence-based, community-based, etc. within a common architecture. A few related posts: http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html , http://improving-bpm-systems.blogspot.com/2011/02/explaining-ea-business-architecture.html and http://improving-bpm-systems.blogspot.com/2010/02/bpm-reference-model-fragment-01.html Thanks, AS

а тема и правда модная, вот такую статью давеча увидел http://club.cnews.ru/blogs/entry/o_sistemah_upravleniya_biznesprotsessami_kejsmenedzhmente_i_aktualnosti_printsipa_britvy_okkama судя по всему мы присутствуем при рождении очередного маркетингового жупела из трех букв?

"issue trackers -- это неформальные младшие братья систем адаптивного управления кейсами" по-моему, хороший issue tracker вроде того же OTRS+ITSM обладает всеми свойствами ACM системы; или я чего-то не замечаю?

Статья эта перепечатана уже в куче мест, но что хотел сказать автор я, честно говоря, не понял. А новорожденному уже года два как.

Отличие в том, что issue tracker - это приложение, а ACM - платформа. В issue tracker зашита предметная область, например, атрибуты issue в нем предопределены. ACM - вещь универсальная. Но если кто-то (например, софтверная компания) смотрит в сторону ACM, чтобы управлять рекламациями, то issue tracker может оказаться более прагматичным выбором.

позволю себе усомниться в моем понимании, ACM - это не "платформа", а некая идеология управления организацией, или методология управления так же и CRM это не платформа, а идеология и методология; и BPM, и ERP платформа появляется там, где эта идеология и методология "обрастает мясом" и становится АС в понимании ГОСТа, то есть системой, состоящей из 1) персонала(!!!) 2) комплекса средств автоматизации его деятельности, и реализует а) информационную технологию выполнения б) установленных функций, в свою очередь в) являющихся составной частью определенных бизнес-процессов так что BPM это идеология и методология, а BPMS - платформа; по уму надо бы также различать CRM и CRMS, ERP и ERPS, ...

из того, что автор - сотрудник компании консалтера/внедренца, я делаю вывод, что он просто готовит почву для впаривания новой модной аббревиатуры-из-трех-букв своим будущим клиентам от статьи поэтому и не требуется быть осмысленной, от неё требуется быть на слуху ;) но я пока ума не приложу, что качественно нового предлагает ACM по сравнению с двумя вариантами: 1) для среды с высокой степенью неопределенности, где почти каждый проход не похож на другой и неизвестно, что тебе вот прям ща на голову свалится (ITSM или орган госвласти, где реализовано "управление по поручениям") - по сравнению с системами incident management типа той же моей любимой OTRS+ITSM; 2) для среды с высокой степенью определенности и небольшой изменчивостью (бизнес-процессы напр. банка, или предоставления государственных услуг) - по сравнению с BPM системой, реализующей версионность процессов (где параллельно могут выполняться instances и предыдущей и текущей свежей версии процесса, а процесс можно корректировать на лету)

Так и есть. ACM зажат между BPM, ECM и issue tracker'ами. Теоретически концепция имеет право на жизнь, а на практике надо отвоевывать место под солнцем и не факт что это получится.

рискну предположить, что получится очередной marketing buzz для напаривания корпоративным заказчикам как минимум, мне трудно представить именно платформу (назовем её условно ACMS) которая бы реализовывала концепцию ACM и при этом чем-то качественно отличалась И от грамотного issue tracker, И от грамотной BPMS

Естественно, я имел в виду технологическую составляющую. Так вот, с точки зрения _технологии_, ACM является платформой, а issue tracker - приложением. Вполне возможно (и я даже знаю такую разработку) реализовать issue tracker, используя ACM в качестве платформы. issue tracker = ACM + разработанные в нем шаблоны.