Описать бизнес процесс кейс

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

Допустим, вы хотите работать автором в «Сделаем» и присылаете портфолио с примерами своих работ. Можно оформить портфолио в виде простого списка с названием работы и ссылкой на нее. Но будет круче, если в описании к каждой знаковой работе вы добавите рассказ: что и для кого сделали, почему приняли такое решение и что получили в результате.

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

Когда надо писать кейсы

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

До и после: бизнес-процессы отдела продаж. Кейс.

Кейс нужен, когда:

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

Сделали что-то сложное, в чем мало кто понимает. Например, мы разобрались,

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

Вот пример кейса «Сделаем» о том, как

А вот пример того, как компания

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

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

Но кейсы подходят не под каждый формат задачи или проекта.

Есть ситуации, когда их не стоит писать:

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

Но можно написать кейс, если вы делаете что-то простое, но много и качественно, или быстро и недорого. Или благодаря вам у заказчика сильно-сильно уменьшилось головной боли. Например, для медиа «Фокус» мы делаем развлекательные посты, но делаем много, быстро и оперативно включаемся в срочные работы.

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

Кейс-интервью McKinsey | Шоколадная фабрика

Как писать кейсы: основные принципы

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

К тому же большинство кейсов строится по стандартной структуре: кто клиент → какая задача → что и как делали → что получилось.

Давайте кратко разберем каждый раздел, из которого состоит кейс.

У кейса должны быть заголовок и превью.

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

Повысили открываемость писем email-рассылки турагентства в три раза

Привели 50 тысяч заинтересованных пользователей на сайт ЖК

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

Написали серию статей про финансы и налоги для блога про бизнес

Написали инструкции для сервиса по продвижению сайтов

Если ваш клиент известный и не против упоминания, можете смело пиариться на названии компании и указать его в заголовке:

Создали удаленную редакцию для Билайн Бизнес

Организовали корпоратив для Газпрома

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

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

Клиент

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

Например, как это делаем мы в своих кейсах:

Задача

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

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

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

Клиент пробовал сам вести соцсети компании, но получалось не очень, поэтому он обратился к нам, иначе не справился бы.

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

Решение

Этот раздел кейса самый объемный. Здесь вы рассказываете, как подошли к решению задачи: как готовились, какую информацию собирали, какие идеи и стратегии предлагали, почему выбрали конкретный вариант и отказались от других. Насколько подробным будет описание, зависит от ваших задач и аудитории.

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

Вот, например, как мы рассказали про подготовку к работе

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

Например, мы рассказали об идеях и показали, как корректировали контент-план

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

Не забывайте иллюстрировать текст. Добавляйте фото, видео, скриншоты, таблицы и графики, которые помогут показать процесс работы. Строите дом — покажите фото стройплощадки и материалов. Придумываете контент для соцсетей — покажите доску с идеями, контент-план, примеры постов.

Например, в нашем кейсе

Результат

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

Если вы еще продолжаете работать над проектом, можно зафиксировать промежуточный результат, которого достигли. Например, вы ведете соцсети компании. Напишите, что количество подписчиков увеличилось на 30% и продолжает расти. Уточните, что продолжаете работать над проектом, и кратко опишите будущие планы — так вы покажете, что клиент доволен вашей работой.

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

Источник: dzen.ru

Кейс-менеджмент: на пути к совершенству бизнес-процессов

Что общего у Федеральной резервной системы США и крупнейшего аэропорта Европы Хитроу? В обеих организациях успешно применяется инновационная система управления кейсами. Она во много раз увеличила эффективность и результативность ключевых бизнес-процессов этих компаний.

Система управления кейсами – это инновационная ИT-система для координации всех «ручных» и автоматических действий при выполнении комплексных однотипных задач (кейсов). Например, в Хитроу в кейс входят все действия служб с момента попадания самолета в зону ответственности диспетчеров и до момента, когда этот самолет покидает воздушное пространство аэропорта.

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

Три ограничения

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

Рассчитанный на 45 млн пассажиров в год аэропорт в последние годы обслуживает около 70 млн человек. Неудивительно, что из-за подобной перегрузки более 30% рейсов вылетали с задержками.

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

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

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

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

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

Пионеры кейс-менеджмента

Разработкой систем управления кейсами занимаются многие компании, но безусловным лидером сегмента является компания Pegasystems (Pega). Она специализируется на данном направлении уже около 30 лет и разработала все прорывные технологии в этой сфере. Именно с историей этой инновационной корпорации неразрывно связано развитие систем кейс-менеджмента.

В конце 1970-х гг. будущий основатель и президент Pega Алан Трефлер принимал участие в создании первых компьютерных программ для имитации игры в шахматы. Это позволило ему получить уникальный опыт в области автоматизации стратегий для решения комплексных задач.

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

Этот разговор подтолкнул Трефлера к созданию компании по разработке инновационных платформ для сквозной автоматизации бизнес-процессов. Разумеется, первым его клиентом стала корпорация Citigroup, а за ней и Bank of America.

Первым ярким достижением Pega, убедительно доказавшим перспективность выбранного подхода к автоматизации банковских процессов, стал масштабный проект в ФРС США в начале 2000-х гг. В результате успешной реализации этого проекта Pega стала первой промышленной ИT-системой, внедренной во всех 12 банках ФРС. Впервые по всей стране был стандартизирован один из ключевых бизнес-процессов ФРС, а количество операционных центров удалось сократить в три раза. Кроме того, заменив единственной ИT-системой множество существовавших, ФРС сократила затраты на ИT на миллионы долларов в год.

Сегодня масштабные решения на базе платформы Pega успешно внедрены в десяти крупнейших глобальных банках, а также во многих лидирующих компаниях других отраслей, в том числе в упомянутом уже лондонском аэропорте Хитроу. Благодаря этому системы управления кейсами стали широко известны и активно применяются в большинстве стран мира, в том числе и в России.

Просто и понятно

Наиболее заметная отличительная черта систем управления кейсами – для их создания и изменения не требуется написание кода.

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

Разработка и изменение систем кейс-менеджмента ведется с использованием понятных бизнесу средств: моделей процессов в Visio или аналогичных редакторах, таблиц правил, подобных Eхсel или на привычном бизнес-языке в Word и т. п.

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

Внедрение системы

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

. сегодня практически невозможно существенно улучшить операционные показатели компании, используя традиционные ИT-системы.

Для внедрения систем управления кейсами применяются два различных пути.

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

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

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

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

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

По сути, аналитики постоянно редактируют уже работающую систему и отвечают за конкретный результат, а не только за «бумажную» часть проекта.

Не для всех

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

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

Таким образом, главное препятствие для распространения философии кейс-менеджмента – консерватизм менеджеров и экспертов.

…главное препятствие для распространения кейс-менеджмента – консерватизм менеджеров.

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

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

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

Интерес к системам управления кейсами в последние годы проявляют и представители таких отраслей, как государственный сектор, здравоохранение, телекоммуникации, транспорт и энергетика. Наиболее масштабными проектами среди перечисленных вертикалей являются Налоговая служба Великобритании, корпорации BP, Ford, Vodafone и Warner Brothers.

Денис Реймер — генеральный директор компании «ЛАНИТ – Би Пи Эм», эксперт журнала «Консультант»

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

Источник: hr-portal.ru

О системах управления бизнес-процессами и кейс-менеджменте

Последнее время в блогосфере ведется активная дискуссия о взаимоотношениях новой модной концепции ACM и BPM. Что же такое ACM: потерянное звено управления бизнес-процессами?

В последнее время в блогосфере ведется активная дискуссия о взаимоотношениях новой модной концепции ACM и BPM . Что же такое ACM: потерянное звено управления бизнес-процессами? Возможность включения человека в BPM ? Или просто система «для бедных», позволяющая реализовать BPM в компаниях сектора СМБ ?

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

Однако достаточно большая часть работ, выполняемых сотрудниками совместно, слабо структурирована, требует обсуждений, выдачи поручений на основе анализа текущей ситуации и контроля сроков исполнения. Для решения подобных задач коллективного взаимодействия сотрудников, управления социальными бизнес-процессами и предназначены системы ACM (Adaptive Case Management).

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

Pidgin-BPM или недостающее звено BPM ?

«BPMs vs. ACM» – противопоставление или интеграция ? ACM это часть BPM или самостоятельная концепция? Многочисленные дискуссии на эту тему буквально вспыхивают на страницах ИТ-изданий. Ответ на этот вопрос зависит от позиционирования ACM. Сегодня наблюдается 2 тенденции среди экспертов.

Частенько при возникновении непредвиденных (для BPM ) проблем приходится отодвигаться от компьютера с его BPM-игрушками и браться за телефон, чтобы «контролировать ситуацию»

Одни эксперты считают, что ACM это Pidgin-BPM, то есть примитивная версия BPM , вульгарным способом решающая те же проблемы. «Серьезные специалисты», отдавшие годы BPMN, BPEL и т.д., принять такую концепцию ACM не готовы. Максимум, на что они вынуждены идти – это считать ACM опцией, дополнительным «бантиком» к BPM . Что интересно: большой вклад в популяризацию такой концепции ACM оказывают посты некоторых известных апологетов ACM. Однако именно практические внедренцы прекрасно понимают, что реальные системы BPM имеют вполне реальные проблемы с целостностью, под которой в данном случае понимаем возможности для удовлетворения всей полноты требований заказчика по автоматизации бизнес-процессов. Хорошо известно, что частенько происходит при возникновении непредвиденных (для BPM ) проблем. Отодвигаемся в сторону от компьютера с его BPM-игрушками и беремся за телефон, чтобы «контролировать ситуацию» – со всеми вытекающими из нее последствиями, в том числе – и с последствиями для такой системы.

Естественно, поставщики давно видят наличие недостатков у «традиционных» BPM-систем . Изобретаются различные возможности добавлять в экземпляр бизнес-процесса в режиме реального времени ad-hoc activity, появляются расширения BPEL для учета коллективного взаимодействия, такие как BPEL4People и пр. Однако эти возможности обладают общими недостатками BPM в сравнении с ACM: требуют сложных настроек (а в ACM их минимум), в них затруднены средства контроля доступа, адресации и фильтрации таких ad-hoc activities, нет средств загрузки файлов, фотографий пользователей, средств для ведения дискуссий – все это элементарные средства, которые обязаны быть в любой ACM.

Результатом такого подхода является ненужный антагонизм между ACM и BPM .

Другие эксперты считают, что ACM это collaborative BPM , social BPM , agile BPM , в которой следующий шаг процесса определяется в социальной среде решением человека. А это как раз то «недостающее звено», которого не хватает традиционному BPM , и по причине отсутствия которого изобретаются BPEL4People etc. В такой интерпретации ACM – это как раз то, чего «жаждет» BPM , без чего BPM не сможет развиваться, чтобы, наконец, стать эффективным инструментом. И интеграция BPM и ACM в этом случае расширяет сферу применения BPM , делает такие системы более привлекательными и эффективными. И те вендоры и интеграторы BPM , кто начинает использовать ACM, получают конкретные конкурентные преимущества

BPM без ACM «выражает одну из основных черт буржуазного мировоззрения — его бесчеловечность, стремление превратить трудящихся в придаток машины, заменить живого, мыслящего, борющегося за свои интересы человека машиной» (1954, Краткий философский словарь о кибернетике). Ну, а если эту мысль выразить более современно, то ACM привносит в BPM необходимую гибкость социальных сетей, «очеловечивает» BPM (не зря же я вспомнил философский словарь советского времени). Кейс-менеджмент позволяет средствами web 2.0 интегрировать BPM с возможностями систем коллективной работы, помогающих принимать решения о следующих шагах бизнес-процесса в социальной среде с помощью обсуждений и поручений.

Преимущества интеграции

Спорное убеждение некоторых, что ACM — это часть BPM , а не самостоятельная «фича», можно было бы усилить идеей о том, что ACM — это не просто дополнительный «бантик» BPM , а критически важная часть решения. Без нее практическая система BPM не является целостной – а отсутствие целостности, недостаток инструментов, собственно, часто и создает известные проблемы при внедрении, то самое желание отодвинуться в сторону от компьютера и взяться за телефон.

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

Такая тактика, как выясняется на практике, является успешной и позволяет за счет ACM сгенерировать новую волну интереса и к BPM , которая при наличии в ней «недостающего звена» ACM, становится существенно более функционально привлекательной для заказчиков и более презентабельной внешне.

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

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

В «обычной» системе BPM вы должны изначально тупо и детально перечислить все возможные варианты до начала процесса, тогда как в ACM эти варианты «подгружаются» из библиотеки паттернов или создаются вручную по мере их появления в реале. Это как сравнивать простую статичную HTML-страницу, которая содержит сразу все – нужное и ненужное, и HTML-страницу с AJAX, которая подгружает данные по мере необходимости. В принципе, можно как-то и простыми HTML-страницами обойтись, зачем этот AJAX? Однако с ним приятнее работать. Так и ACM «проявляет» процесс по мере его исполнения.

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

Циклами Птолемея тоже, в принципе, движение звездных тел описывалось – с любой наперед заданной точностью.

Принцип Оккама безвозвратно забыт

Принцип бритвы Оккама — «не изобретай сущностей сверх необходимых» — безнадежно забыт очень многими вендорами ИТ. Нынешний мировой тренд поставщиков программного обеспечения можно выразить фразой: «Новизна подменяется сложностью». Когда сказать нечего, идей нет, а новые версии надо выпускать, чтобы увеличивать доход, тогда и выпускаются на рынок софтверные монстры. И с BPM такая же история.

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

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

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

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

Для ACM такой чек-лист из контрольных точек – это то же самое, что для «традиционного» BPM — «happy path», основной перечень действий, которые надо сделать, и представление о которых имеется перед началом процесса. В ACM этот перечень по мере исполнения процесса корректируется и дополняется.

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

Фильтры позволяют увидеть и на лету сформировать все такие необходимые списки контрольных точек в разных разрезах.

Пример списка контрольных точек

● «Открытые» – актуальные сообщения;

● «Требующие ответа» – сообщения, требующие создания ответных сообщений;

● «Просроченные» – открытые сообщения с просроченной датой исполнения;

● «Созданные мной» – сообщения, созданные текущим пользователем;

● «Для меня» – сообщения, адресованные текущему пользователю.

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

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

Малому бизнесу нужны «варенки с вьетнамского рынка»

Зададим два простых вопроса. Какой процент крупных компаний используют системы BPM ? 15%? Значит, есть куда расти. А какой процент малых предприятий используют пользуются такими системами? 0,01%?

Значит, тут у «традиционных» систем BPM шансов нет.

«Чистые» BPMS являются элитарными продуктами, как джинсы от Versace? и малый бизнес никогда не сможет их использовать. А вот внедрение систем ACM в силу их простоты и доступности смогут провести 90% СМБ-предприятий, ведь простая система управления задачами, где можно галочкой отмечать исполненные работы, нужна практически всем. Такие системы будут, как «варенки с вьетнамского рынка» — дешевый и доступный товар массового спроса. Конечно, такие «варенки» не станут мейнстримом, функционал которого дотошно обсуждается ИТ-менеджерами высокого класса в специализированных блогах. Просто все будут использовать эти решения – без всякого почитания и ритуальных танцев с описанием бизнес-процессов и выдумыванием толстых технических заданий.

Так что для элитарных BPMS со стороны ACM опасности никакой: BPMS на рынок СМБ и не претендуют, их присутствия в этом секторе не ощущается, у них пока достаточно проблем и с крупными заказчиками. ACM это «BPMS для бедных»? А почему бы и нет?

И еще о сложных и простых ИТ-платформах

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

Ну а «кадры» очень часто недовольны. И именно ИТ-специалисты компании-заказчика зачастую влияют на выбор неоправданно сложной системы с неоправданно сложной архитектурой, тем самым укрепляя свою незаменимость. Пользователи интуитивно это чувствуют, но ни доказать, ни сделать что-либо не могут. Конечно, они недовольны — кто-то осмысленно, кто-то интуитивно.

Известный факт: сисадмина, у которого все хорошо, никто не замечает. А вот сисадмина, у которого все ломается, носят на руках, как героя, который всех спасает в критический момент.

Уже давно очевидно, что, предлагая простой в эксплуатации эффективный продукт со 100%-й гарантией успешного внедрения, ты, возможно, лишаешь себя наиболее крупных заказчиков с многочисленным ИТ-штатом. Профильные спецы по доброй воле никогда такой продукт не выберут – позже их может заставить это сделать жизнь или же собственное начальство, озверевшее от жалоб пользователей на систему, работающую только в присутствии ИТ-шников.

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

При этом очевидные факты, что «решениям от очень крупного вендора» свойственны очень высокая стоимость владения (TCO), сомнительный возврат инвестиций (ROI) и высокий риск провала внедрения, в расчет не принимаются – ИТ-бюджет позволяет за все заплатить. Фактический провал такого внедрения долго никем не признается – никому это не выгодно – и решение существует в вялотекущем режиме, используется 10% заявленной функциональности. Но архитектура стоит очень крутая (ну и дорогая, соответственно). Виноваты все, кроме принявшего «правильное» решение менеджера.

Иногда только публике становятся известны удивительные факты судебных исков против поставщиков ERP о возмещении убытков на сотни миллионов долларов.

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

Источник: ecm-journal.ru