Несколько дней назад я предложил устроить небольшой опрос на тему способная ли ACM заменить BPMs. На мое предложение откликнулся Анатолий Юмашев, которого читатели этого блога знают не только по полезным комментариям, но и благодаря открытой облачной платформе для эффективного управления бизнес-процессами и документооборота (CRM, ACM, ITSM, CMDB …) casepress.org. Хочу искренне поблагодарить Анатолия за ответы. Позволю и себе высказать некоторые комментарии.
Как Вы думаете, может ли ACM стать “подрывной” технологией для BPMs, т.е. классом систем, который со временем отберет у BPMs значительную часть заказчиков?
Анатолий Юмашев ACM не будет подрывать BPM. Она ее поменяет. Это не конец BPM, а революция, может быть даже эволюция. Само понятие управления процессами (BPM) никуда не подорвется. Оно останется, но сильно поменяется и просто центр тяжести сместится от схем и функций, к сообщениям (кейсам) и чек-листам как когда то это случилось в мире разработки ПО (переход от функциональной разработки, к ООП). Но в мире организаций, это даже не прогресс, это регресс. Мы возвращаемся к давним и хорошо забытым техникам, просто в новой форме – веб страниц.
Максим Смирнов Я тоже не думаю, что ACM заменит BPMS. Сегодняшним системам управления бизнес-процессами скорее стоит опасаться того, что принято называть SaaS BPM, решений типа Signavio или KissFlow, позволяющих неподготовленному пользователю быстро набросать простой workflow. Одна из основных идей BPM в том и состояла, чтоб передать ответственность за разработку и развитие процессов пользователям, исключив из этого цикла ИТ. Можно сказать, что изначально BPMS и позиционировался как Digital Workflow. Другой вопрос в том, что для многих задач полноценное BPMS решений просто не нужно. «Заявки», «Согласования» и т.п. можно делать куда более простыми и дешевыми инструментами.
Какими тремя функциями BPMs (графическая нотация, симуляция, аналитика, интеграция и т.п.) должна обладать ACM система, чтоб заместить BPMS (Если ответ на первый вопрос отрицательный, то соответственно отсутствие каких функций в ACM не позволят ей заменить BMPS)
Анатолий Юмашев Учет и контроль операций процесса, аналитика и интеграция. Схемы, нотации, симуляции – это лишнее. Потому оно отпадает как шелуха.
Максим Смирнов Абсолютно согласен.
Какие мотивы подталкивают организации внедрять BPM/ACM и каковы другие решения, способные более просто удовлетворить подобные потребности.
Анатолий Юмашев Мотив прост – нужно быть уверенным в том что конечный результат получается таким, каким ожидаем. Нужна предсказуемость. Нужна информация о состоянии дел и показателях, еще точнее о их динамиках, и возможности для снижения операционных затрат на единицу продукции. Когда то для этих целей использовались журналы по правилам ГСДОУ для регистрации записей документов и формы документов, с полями и чек листами или определенными нормами заполнения, составом реквизитов – для контроля данных о ситуации. Это и до сих пор является рабочим инструментом и много где применяется. Бумажные журналы легко поменять на Google Таблицы или MS Excel. Как впрочем и формы. В процессах с малым количеством операций или в трудно доступных местах такие решения вполне себя оправдывают. Но если операций много и данные о них востребованы многократное в перспективе, то тут уже нужна БД и потому тут начинают внедряться решения класса BPM/ACM.
Максим Смирнов А вот здесь я не вполне согласен. Для получения информации о состоянии дел обычно достаточно системы управленческой отчетности. В крайнем случае, может потребоваться dashboard, оперативно отображающий нужную информацию. Внедрение BPM системы это типичные проект внедрения suite, когда для реализации одной реальной потребности приходится сначала перепахать множество связанных процессов и систем и результата можно и не дождаться. Впрочем, если делать автоматизацию с нуля, то может быть такое решение и оправдано.
Анатолий, еще раз спасибо за ответы. Если кто-то захочет что-то добавить, пишите.
casepress.org сразу прилег отдохнуть после такой рекламы )))
Реклама, это когда за деньги. А когда просто так, это гиперссылка 🙂
Максим, по последнему абзацу, я согласен с не согласием 🙂
Но нужно понимать что у нас разные весовые категории. Я говорю больше про малый бизнес. А там мало кто понимает фразу “системы управленческой отчетности”.
Но вот с чем согласен, так это с dashboard. Я еще пару лет назад мечтал о OLAP/BI и мой последний проект провалился, уступив конкуренту – наспех сделанному дашборду )) Как оказалось те кто способен осилить OLAP – могут сваять аналитический разрез и в Excel. А те кто не способен – им проще открыть страничку с заготовками, где сразу проявляются графики текущей ситуации.
Ну и в остальном согласен. Да, в среднем и крупном бизнесе казалось бы мелкая задача, чего там делать? Но вот проходит год а воз и ныне там… начинаешь копать и вырываешь кучу мелких “потому что” в разных местах организации. И это куча мелочи в итоге тормозит весь прогресс. И обычно у меня тут возникает мысль “вот бы по этой задаче да из ACM бабахнуть”, но нет там ACM 🙂 и остается только соболезновать руководству такой организации. Помню что Вы где то в своих заметках назвали этого зверя complexity.
Вопросов нет. Все так. Но не в малом бизнесе 🙂 В малом бизнесе другой масштаб проблем и там ближе логика описанная в моей заметке 🙂
А зачем малому среднему, да и любому по размеру, бизнесу рассматривать изначально интеграционные решения? Бизнесу нужны решения с помощью которых можно создавать свою добавленную стоимость, а не заниматься разработками и сопровождением интеграционных решений. Сама логика применения и BPMS и АСМ страдает от необходимости интеграции. Любой выход за пределы одной системы для решения других задач связанных с деятельностью организации ведет к потере информации в одной из используемых систем, либо увеличивает количество операций, подверженных дублированию, отражению их состояния в разных ИС, решающих ту или иную задачу управления.
Не проще ли используя единую модель деятельности идти к единой системе менеджмента (ИС) – системе, в которой нужные инструменты внутри системы, имеющей единую СУБД, позволяющую реализовать принцип ввода данных один раз в одном месте достигая целевой задачи – управления ресурсами? Суть адаптивности и применения процессов и проектов в этом случае принципиально иное.
Причина проста до жути.
Интеграция – понятие широкое. Например у нас из коробки система интегрирована на уровне гиперссылок. Скажем договор в системе ERP имеет гиперссылку на свою копию в системе бух учета. Потому что обе системы – в веб.
Попробуйте сделать тоже самое скажем с 1С и SAP. Вам придется не слабо так вспотеть. Даже если речь о 1С-веб. Я ее вот тут обоснованно назвал 1С-недовеб http://casepress.org/mozhno-li-rabotat-s-1s-v-rezhime-veb-versii/
И это можно сказать что и не интеграция, т.к. не потратили мы на нее ни копеечки. Просто она нам досталось в наследство от веб-технологий. Но выберите иные решения – и там так просто уже не получится.
Но и это лишь то что идет из коробки. На самом деле вы удивитесь, но многие малые бизнесы сейчас заказывают интеграцию своей ERP и своего сайта. Это вполне себе популярные решения. При этом они уходят от своих старых ERP потому что там нет такой возможности. И это речь именно о микро бизнесе где работают 10-20-30 человек.
Не говоря уже о возможности получать заказы с сайта или делать порталы обслуживания своих клиентов через веб.
Единая система под все что можно выдумать – это фантазия. Как коммунизм. Секрет в правильном подборе компонентов и правильной интеграции, когда можно взять сильные стороны каждого продукта. Например мы пока что не собираемся интегрировать календарь и чат в свою систему, т.к. они много лучше сделаны в почтовых решениях типа Google, Mail.ru или Яндекс.ПДД. И нам проще интегрироваться с ними, чем дублировать их функционал у себя. А самим заниматься тем что лучше всего получается – это развитие идей ACM и коммуникации в рамках кейсов.
Адаптивность в нашем понимании это ровно как возможность интеграции с чем то внешним, так и возможность добавить этот функционал внутрь системы, если оно оправданно экономически. А не попытка уходить в крайности – только интеграция или совать все внутрь отторгая внешние продукты.
Уже лет двадцать не утихает спор о том, какие решения лучше использовать, то что называется best-of-breed или полнофункциональный suite. Ответ зависит от отрасли и от степени зрелости соответствующей технологии.
Появилась мысль касательно данного утверждения 🙂
С ходу могу назвать где выигрывает best of bread и проигрывает suite. А вот обратные случаи как то в голову не приходят…
Андроид, iPhone, все современные веб приложения так или иначе поддерживают друг друга и взаимодействуют.
Из обратных примеров Nokia с Simbian, 1С. Попытка запихнуть весь функционал в одну платформу. Получается как то, функции как бы работают но их качество далеко от нормы. Потому что компонентов много и на каждый приходится слишком мало внимания.
И тут стоит вспомнить слова известного ИТ-мудреца:
Ключ к тому, чтобы делать большие и расширяющиеся системы, заключается в том, чтобы придумывать, как модули будут общаться друг с другом, а не заботиться об их внутренних свойствах и поведении. Аллен Кей (автор концепции ООП)