Нужен ли CIO BPM

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

BPM — это одновременно и управленческая методология, и технология. Одного без другого не существует, поскольку автоматизация бизнес-процессов без понимания концепции постоянного усовершенствования бесперспективна, а управление бизнес-процессами без автоматизации — неэффективно. Принято считать, что когда речь идет об автоматизации, то исполнителем является ИТ-служба. В случае с BPM дело обстоит иначе. Разберемся, кто действительно заинтересован во внедрении ВРМ и кто этим должен заниматься.

Что сегодня успешно делают ИТ

Как сегодня обстоит дело с автоматизацией предприятий? Можно утверждать, что: а) компьютеры есть у всех; б) бухгалтерия не пользуется счетами; в) в качестве средств коммуникации используются электронная почта и ICQ. Дальше все зависит от степени развитости ИТ-службы и от объемов финансирования. Наиболее распространенный вариант — в компании внедрена полностью либо частично покупная интегрированная информационная система, которая дополняется разрабатываемыми самостоятельно либо на заказ приложениями.

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

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

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

Чего хотелось бы бизнесу, или За что готов платить руководитель

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

Без сомнения, надежный тыл в виде стабильно работающих служб, который обеспечивает ИТ-департамент, важен. Но руководитель при этом имеет только инструменты контроля в виде отчетов и сводок, составленных по состоянию на определенный момент времени, отражающих, в лучшем случае, только то, что было вчера. Насколько удобно использовать такую информацию, когда постоянно меняются курсы валют, рынки, конкуренты, условия сделок? Для принятия решений нужны не отчеты не первой свежести, а то, что на английском языке называется «agility», то есть - «способность замечать происходящие изменения и быстро на них реагировать».

Езда на разных скоростях

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

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

Между шагами 1 и 3 образуется барьер: семантика кодов бизнеса и ИТ различна, поэтому бизнес не может напрямую воздействовать на полученный результат. В итоге приходим к реализации неточно понятых требований, которые, к тому же, на момент готовности уже не отвечают сегодняшним потребностям бизнеса. Любые изменения требований — это новый цикл разработки. Другими словами, информационные технологии постоянно догоняют бизнес и всегда проигрывают. Необходимо четко понимать: правила всегда устанавливает бизнес. Задача ИТ — научиться жить по этим правилам. Их не так уж и много: скорость и изменчивость.

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

Таблица. Календари бизнеса и ИТ

Бизнес просто не может ждать ИТ, и если ничего не предпринимать, то разрыв будет только увеличиваться. Выход один — привести ИТ-календарь в соответствие бизнес-календарю. Для этого необходимо отдать бизнесу ту часть работы, которую он должен делать сам, сократить цикл разработки и избавиться от переписывания программ.

Какую работу ИТ-департамент может отдать бизнесу? Например, создание диаграмм. Но не текстовых документов, а исполняемого кода! И это не фантазии. Для того чтобы избежать издержек транслирования описаний в программный код, необходимо, чтобы описания создавались в том же коде. Но аналитик никогда не будет описывать бизнес на языке программирования! Следовательно, необходимо программное обеспечение, способное превращать диаграммы в программный код. Подход «что вы моделируете, то мы и исполняем» реализован в системах управления бизнес-процессами (Business Process Management Systems, BPMS). Но раз уж схема переводится автоматически в программный код, то этот код должен быть исполняемым. Аналитик рисует схему бизнес-процесса, сохраняет ее на сервере, после чего шаги процесса превращаются в задания для пользователей. А для выполнения заданий пользователям необходим интерфейс — воспроизводство задания на экране. Такой интерфейс создается BPM-системой автоматически.

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

Что означает «сократить цикл разработки»? Традиционная модель разработки (так называемый водопад) делится на четко определенные фазы, выполняемые строго последовательно: требования, анализ, разработка, тестирование, ввод в эксплуатацию (см. рис. 1).

Рис. 1. Модель «водопад»

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

Рис. 2. Итеративная модель

В BPM-системе задание от аналитика передается в ИТ-отдел в виде исполняемого кода, в результате чего максимально сокращаются этапы «Требования» и «Анализ». Таким образом, цикл разработки сокращается, а следовательно, сокращается и время разработки.

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

За время своего существования любая организация обрастает множеством осознанно приобретаемого и стихийно создаваемого программного обеспечения. Многие программы создаются «временно», для того чтобы решить конкретную насущную проблему, но затем приживаются и остаются надолго. Что же делать с этими программами? Переписать во что-то одно и большое? Попробовать втиснуть в уже имеющуюся систему? Практика показала, что окончательного решения проблемы ни одним из этих методов достичь не удается. Еще один способ — интеграция. Можно непосредственно связывать приложения и системы между собой, но можно делать это внутри бизнес-процессов. BPM-системы позволяют делать это любым из существующих способов : путем непосредственного обращения к данным, обращением к функциям, а также при помощи Web-сервисов. Хорошо вписываясь в концепцию сервис-ориентированной архитектуры (SOA), BPMS позволяет выстроить гармоничную цепочку взаимодействия людей и систем и избавиться от необходимости переписывать программы.

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

Подводные камни

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

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

Получая карт-бланш в этом направлении, ИТ-директор получает рычаги управления, но, передавая BPM, руководство теряет интерес к предмету, и через некоторое время BPM превращается в очередной проект автоматизации. Предположим, что вы автоматизировали один или несколько процессов. Результат удовлетворил руководителя. Будете ли вы сознательно вносить изменения в процесс и что-то переделывать? Если да, то придется объяснять руководителю, зачем вы это делаете, своими руками создавая себе работу. Предположим, что вы достаточно твердо следуете основному принципу BPM — принципу постоянного улучшения. Но что именно вы будете улучшать? Бизнес? Но это, простите, не ваша задача, если, конечно, вы не преследуете цель занять место вашего руководителя. Если ваше место вас устраивает, то у вас есть шанс серьезно укрепить свои позиции, дав возможность (именно инструментальную возможность) руководителю самому управлять бизнес-процессами. От вас же требуется техническая и аналитическая поддержка. Не взваливая на себя, а именно разделяя с руководителем ответственность за BPM, вы реально можете повысить свой статус в компании.

Второе заблуждение — это попытка оценить стоимость процесса под ключ. И попытка представить заказчику (как внешнему, так и внутреннему) стоимость разработки процесса — это второй подводный камень.

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

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

Пройдет ли мода на BPM?

Стоит ли затевать всю эту игру в BPM, если через несколько лет, возможно, не останется даже такой аббревиатуры?

Действительно, BPM так быстро меняется и трансформируется, охватывает все большие зоны и управления, и автоматизации. Поэтому не прекращаются попытки придумать «самое последнее правильное название». Возможно, что какое-то новое название и приживется — это лишь станет отражением более глубокой формы. Еще пару лет назад BPMS расшифровывали как Business Process Management System, а теперь обоснованно под «S» понимают «Suit». Что это изменило? Только расширило понятие. Можно ожидать, что дальше станут употреблять термин «платформы», поскольку именно в этом направлении ведется активная работа. Но согласитесь: то, что пришло вместе с BPM — моделирование с автоматическим исполнением, бесшовная интеграция, тонкий клиент — уже стало входить в норму.

Сейчас большинство BPM-поставщиков предоставляют бесплатные ознакомительные версии своих продуктов. Среди тех, кто запрашивает ознакомительные версии, примерно 30% составляют студенты, 20% — программисты, 40% — топ-менеджеры и аналитики, 10% — ИТ-директора. Это говорит о том, что бизнесу нужен BPM. Те, кто еще не достигли высот, видят в BPM перспективу, и не все ИТ-директора против BPM.

Сможет ли ИТ-директор обойтись без BPM? Возможно, да. Но BPM без поддержки ИТ-директора обойтись не сможет.

Юлия Вагнер — начальник отдела технической поддержки компании «Бизнес-Консоль»; julia@b-k.ru