| Все о системах управления |  |
| Почитать |
| Поговорить |
| Побродить |
| Завершить |
|
|
||||
|
Нужен ли CIO BPM?
|
|||||
Литература:
Автор: Юлия Вагнер
Оригинал статьи: "BPM: нужен ли он CIO?"
BPM – это одновременно и управленческая методология и технология. Одно без другого не существует, поскольку автоматизация бизнес-процессов без понимания концепции постоянного усовершенствования бесперспективна, а управление бизнес-процессами без автоматизации – неэффективно. Но это теория. А делать-то кому? Кто в этом заинтересован и кто это выполняет? Казалось бы, понятно – если автоматизация – значит ИТ. Но в данном случае это привычное правило не сработает.
Что сегодня умеет и успешно делает ИТ
Точнее – как сегодня обстоит дело с автоматизацией предприятий?
Можно утверждать, что: а) компьютеры есть у всех; б) бухгалтерия не пользуется счетами; в) в качестве средств коммуникации используются электронная почта и ICQ. Дальше все зависит от степени развитости ИТ-службы и от объемов финансирования. Наиболее распространенный вариант - покупная корпоративная информационная система (КИС), которая дополняется разрабатываемыми самостоятельно либо на заказ приложениями. Такие системы автоматизируют определенные функции или наборы функций.
Первоочередная задача ИТ – обеспечить своевременную настройку/донастройку существующих систем, интеграцию данных между разными приложениями, разработка либо приобретение недостающего программного обеспечения. И делать это надо так, чтобы не прерывать деятельность других служб и отделов. Одним словом – работы хватает. Вот только высшее руководство не хочет вникать в проблемы, постоянно выставляет новые требования, которые нужно реализовать «еще вчера». Причем, назавтра все меняется, так что иногда проще не делать и подождать, пока «само рассосется».
Руководству приходится постоянно объяснять, что есть стандартный, проверенный годами путь – ТЗ, проектирование, разработка, тестирование, опытная эксплуатация, доработка… и где-то вдали маячит промышленная эксплуатация. И когда требования меняются, приходится начинать все заново. Отсюда и кажущееся топтание на месте, хотя в действительности сотрудники постоянно «в запарке», а коды можно измерять в километрах.
При этом мало кто задумывается, что благодаря ИТ сотрудники других служб вовремя вводят и получают информацию, вовремя предоставляют отчетность. Почему не задумываются? Да потому, что это совершенно нормально – именно так и должно быть! Руководителя мало интересует, как именно собирается информация или составляется отчет – его интересует, чтобы это было сделано, и сделано вовремя. Для руководителя ИТ департамент – это всего лишь еще одно обслуживающее подразделение.
Чего хотелось бы бизнесу или за что готов платить руководитель
Вы когда-нибудь задумывались над тем, почему для руководителя или собственника бизнеса вовремя заключенный контракт важнее вовремя сданного отчета? Конечно, отчет должен быть сделан качественно и в срок. Но есть целый штат людей, которые этим занимаются и которым он, между прочим, платит деньги. А вот выгодная сделка – это то, что будет приносить компании деньги. И доверить такую работу обычному сотруднику руководитель едва ли согласится – тут и объяснять нечего. И если вы попытаетесь ему объяснить, что условия сделки должны соответствовать возможностям вашего программного обеспечения… не думаю, что кто-то, даже очень уважаемый CIO, отважится это предложить. И если назавтра выяснится, что имеющееся ПО или настройки чего-то там не поддерживают, то руководитель скорее откажется от автоматизации, чем от контракта.
Без сомнения, надежный тыл в виде стабильно работающих служб, который обеспечивает ИТ департамент – это важно, это отмечается руководством (иначе бы разогнал всех давно!). Но сам руководитель при этом имеет только инструменты контроля – в виде отчетов и сводок. Как правило, эти отчеты составляются в установленные сроки и содержат данные по состоянию на определенный момент времени. Грубо говоря, ваш руководитель может видеть, в лучшем случае, только то, что было вчера. Возможно, что вчера этого было достаточно. Возможно, что кто-то и по сей день работает именно так. Но это вовсе не значит, что нужно продолжать так работать или ждать, когда остальные будут работать по-новому, чтобы перенять опыт.
Поставьте себя на место руководителя: постоянно меняется все – курсы валют, рынки, конкуренты, условия сделок. Заказчики отказываются заключать договора на прежних условиях, поставщики перешли на предоплату… это далеко не все проблемы, с которыми ваш шеф сталкивается по нескольку раз на день. И решения необходимо принимать не через неделю, и даже не через день, а иногда – прямо сейчас. И нужны ему для этих решений не отчеты не первой свежести, а то, что на английском языке называется «agility», а на русский переводится длинным предложением «способность замечать происходящие изменения и быстро на них реагировать».
Не так давно в обиход вошли термины «Lean manufacturing», «Six Sigma», «бизнес-процессы», «BPM» - где-то рядом, и чутье подсказывает, что надо двигаться в этом направлении – но как именно двигаться? К ИТ обращаться не хочется – опять все годами, а надо сейчас…
ИТ и бизнес: езда на разных скоростях
В последнее время все чаще можно встретить в обсуждениях и статьях термин «разрыв между бизнесом и ИТ». Явление само по себе непонятное - как получилось, что бизнес и ИТ стали отдаляться друг от друга? Почему бизнес больше не ищет поддержки у ИТ, а стремится обойтись своими силами?
Очевидно, проблема в разнице между тем, что реально хочет бизнес и тем, как ИТ понимают и реализуют эти требования. «Недовольство» бизнеса можно выразить так:
- Результат автоматизации отличен от того, что ожидал бизнес
- Процесс создания автоматизированных решений слишком долог, дорогостоящ и с трудом поддается управлению
Кто в этом виноват? Стандартная практика разработки выглядит следующим образом:
- Бизнес формулирует свои требования в доступной ему семантике: описывает свои требования в виде текстового документа либо, что преобладает в последнее время – в виде схем, описывающих последовательность действий исполнителей.
- ИТ получает и анализирует эти требования с точки зрения имеющейся архитектуры и технических возможностей.
- ИТ интерпретирует полученные требования в программный код.
- ИТ передает бизнесу полученный результат.
Между пунктами 1 и 3 образуется барьер: семантика кодов бизнеса и ИТ различна, поэтому бизнес не может напрямую воздействовать на полученный результат. Учитывая, что реализация требований занимает достаточно много времени, на 4 этапе может оказаться, что результат не совсем тот, да и к тому же уже не отвечает сегодняшним потребностям бизнеса. А любые изменения требований – это снова 1,2,3,4. Т.е. ИТ постоянно догоняет бизнес, и эта гонка для него всегда проигрышная. Отсюда и недовольство ИТ: невозможно сделать что-либо стоящее, если требования постоянно меняются. «Вы сначала определитесь, а потом требуйте!». Резонно, но для бизнеса, увы, неприемлемо.
Давайте сравним календари бизнеса и ИТ:
Бизнес-календарь | ИТ-календарь | ||
Бизнес-решения | минуты | новые бизнес-приложения | месяцы |
Бизнес-анализ | дни | интеграция приложений | месяцы |
Интеграция активов | недели | настройка и внедрение ERP (CRM, SCM, BSC, BI…) | годы |
Выход на новые рынки | месяцы | новые версии ERP | годы |
Изменения бизнес-ландшафта | месяцы | изменение настройки ERP | практически |
появление новых технологий | годы | ||
Проблема – во времени реакции на изменения. Бизнес просто не может ждать ИТ. И если ничего не предпринимать, то со временем этот разрыв будет только увеличиваться. И тут нет иного выхода, чем привести ИТ-календарь в соответствие бизнес-календарю. Для этого необходимо:
a) отдать бизнесу ту часть работы, которую он должен делать сам
b) сократить цикл разработки
c) избавиться от переписывания программ.
Какую работу ИТ может отдать бизнесу? Речь идет о создании диаграмм. Но не текстовых документов, а исполняемого кода! И это не фантазии. Для того чтобы избежать издержек транслирования описаний в программный код, необходимо, чтобы описания создавались в том же коде. Но аналитик никогда не будет описывать бизнес на языке программирования! Следовательно, необходимо программное обеспечение, способное превращать диаграммы в программный код. «What you model is what we run» (Что вы моделируете, то мы и исполняем) - этот подход реализован в системах управления бизнес-процессами – BPM-системах (BPMS). Но раз уж схема переводится автоматически в программный код, то этот код должен быть исполняемым, что мы и имеем в случае с BPMS. Аналитик рисует схему бизнес-процесса, сохраняет ее на сервере, после чего шаги процесса превращаются в задания для пользователей. А для выполнения заданий пользователям необходим интерфейс – воспроизводство задания на экране. Такой интерфейс создается BPM-системой автоматически.
Что же в этом случае делать специалистам ИТ? Разберемся с «зонами ответственности». Пользовательский интерфейс, который система создает автоматически – это только необходимый набор полей для отображения атрибутов процессов. Но в промышленной эксплуатации мы привыкли пользоваться справочниками, поиском, подсказками и прочими удобными вещами, которые автоматически созданный интерфейс не обеспечит. Кроме того, в процессе необходимо использовать данные из других систем и источников. Все это – зона ответственности ИТ. То, что создает аналитик – это лишь прототип процесса, который уже исполняем, но ограничен в удобствах. Такой прототип может быть запущен в эксплуатацию, но только как временное решение, ожидающее доработки со стороны ИТ. С точки зрения ИТ-специалиста «то, что не до конца автоматизировано, не должно быть передано в эксплуатацию» - знакомо? Но с точки зрения бизнеса «то, что хотя бы частично автоматизировано, то уже освобождает руки и голову». Пусть система начинает работать и приносить пользу как можно раньше, и пусть к этому прикладывают руки аналитики. Это, в свою очередь, позволит более продуктивно использовать ресурсы ИТ.
Что означает «сократить цикл разработки»? Традиционная модель разработки (так называемый «водопад») делится на четко определенные фазы, выполняемые строго последовательно: требования, анализ, разработка, тестирование, ввод в эксплуатацию (Рис.1.).
Рисунок 1. Модель «водопад»
Такой подход хорошо работает в проектах, где требования могут быть четко определены и зафиксированы. Но в условиях постоянно изменяющейся бизнес среды и, тем более, в соответствии с концепцией непрерывного усовершенствования, на которой основан BPM, требования постоянно меняются. Следовательно, в данном случае более уместен итеративный подход к разработке. Процесс состоит из серии повторяющихся итераций (их число зависит от конкретного проекта), каждая из которых фактически является полноценным мини-проектом с фазами определения требований, анализа, разработки, тестирования, внедрения (Рис.2.). В результате очередной итерации продукт приобретает новую функциональность или улучшения в существующей функциональности. Полный набор требований, зафиксированный границами проекта, оказывается реализованным после завершения финальной итерации.
Рисунок 2. Итеративная модель
Что нового добавляет в эту модель BPMS?
Благодаря тому, что задание от аналитика передается в ИТ в виде исполняемого кода, максимально сокращаются «Требования» и «Анализ». Таким образом, цикл разработки сокращается, а, следовательно, сокращается и время разработки.
Создаваемый аналитиком прототип процесса – это уже рабочий процесс с ограниченными удобствами. После тестирования этот процесс может быть запущен в работу. В первое время пользователям придется заполнять часть данные на форме вручную (например, путем копирования их из другой системы). Но если процесс решает помимо задач автоматизации и определенные бизнес-задачи, то даже при ручном вводе процесс дает отдачу. Наращивание функциональности можно проводить постепенно, не останавливая процесс. Такой подход позволяет максимально сократить время от разработки процесса до его эксплуатации.
(Замечание: организация проектов BPM разделяет основные принципы agile development, и это не случайное совпадение. Поэтому организации, присматривающейся к BPM, настоятельно рекомендуется начать внедрять у себя эти принципы.)
За время своего существования любая организация обрастает множеством осознанно приобретаемого и стихийно создаваемого софта. Многие программы создаются «временно», для того, чтобы решить насущную проблему, но затем приживаются и остаются надолго. И каждый раз, когда в «зоопарке» появляется новый «обитатель» или планируется реконструкция самого зоопарка, возникает вопрос: что делать с этими программами? Переписать во что-то одно и большое? Попробовать втиснуть в уже имеющуюся систему? Поступают и так, и так. Но практика показала, что конечного решения проблемы ни одним из этих методов достичь не удается. Еще один способ – интеграция. Можно непосредственно связывать приложения и системы между собой, но можно делать это внутри бизнес-процессов. BPM-системы позволяют делать это любым из существующих способов – путем непосредственного обращения к данным, обращением к функциям, а также при помощи веб-сервисов. Хорошо вписываясь в концепцию SOA (сервис-ориентированной архитектуры), BPMS позволяет выстроить гармоничную цепочку взаимодействий людей и систем и избавиться от необходимости переписывания программ.
Не секрет, что для бизнеса ИТ часто выглядит как «черный ящик», если не сказать, как «ящик Пандоры» - никогда не известно сколько в него нужно вложить и что оттуда появится. Для кого-то это может казаться удобным, но для ИТ-директора, который мыслит стратегически, гораздо выгоднее сделать работу ИТ прозрачной для руководителя, что вполне позволяют современные технологии.
Подводные камни для CIO
Несмотря на постоянный упор на методологическую составляющую BPM, этот термин прочно ассоциируется с ИТ . Действительно, если речь идет о полноценном управлении бизнес-процессами, то обойтись без автоматизации не удастся. Поэтому, как правило, в решении браться или не браться за BPM веское, если не решающее слово принадлежит CIO. Тем, кто уже сказал свое твердое «нет» BPM, эти подводные камни уже не страшны. С чем же могут столкнуться сторонники BPM?
Несколько типичных ситуаций, наблюдаемых у заказчиков:
- Руководитель уже много наслышан о бизнес-процессах, ему нравится, что есть система, в которой он сам (или бизнес-аналитик) может самостоятельно рисовать и изменять схемы процессов. Начинаем работать. Вопрос: «Кто будет рисовать схему?» Ответ: «Да я в ИТ все передал – пусть разбираются!»
- Заказчик полностью согласен с концепцией постоянных улучшений, понимает, что процессы должны постоянно изменяться и усовершенствоваться. Вопрос: «Сколько стоит разработка процесса «под ключ»?»
О чем это говорит? О том, что для многих бизнесменов BPM еще не стал потребностью, они готовы делегировать управление своими бизнес-процессами людям, далеким от его собственного бизнеса – в первом случае – ИТ-департаменту, во втором – сторонней организации. Это не значит, что ни те, ни другие не смогут описать и автоматизировать процессы. Но бизнес, который за тебя строят другие, обезличивается, теряет индивидуальность. Нельзя ожидать нестандартных свежих решений там, где вы идете на поводу общепринятых шаблонов.
Нет ничего необычного, что разбираться со всеми новинками всегда предлагают ИТ. Эти люди обладают аналитическим складом ума, что делает их «мастерами на все руки». Однако, правильно ли это в случае BPM? С одной стороны, получая «карт-бланш» в этом направлении, CIO получает рычаги управления. Но с другой стороны, передавая BPM CIO, руководство теряет интерес к предмету, и через некоторое время BPM превращается в очередной проект автоматизации. Задумайтесь, какова цель CIO? Выполнить работу и показать руководителю конечный результат. Предположим, что вы автоматизировали один или несколько процессов. Результат удовлетворил руководителя. Вопрос: будете ли вы сознательно вносить изменения в процесс и что-то переделывать в этом случае? Зачем? Ведь тогда: а) придется объяснять тому же руководителю, зачем вы это делаете; б) своими руками создавать себе работу. Предположим, что вы достаточно твердо следуете основному принципу BPM – принципу постоянного улучшения. Но что именно вы будете улучшать? Бизнес? Но это, простите, не ваша задача. Если вы преследуете цель занять место вашего руководителя – тогда да. Но если ваше место вас устраивает, то у вас есть шанс серьезно укрепить свои позиции, дав возможность (именно инструментальную возможность) руководителю самому управлять бизнес-процессами. От вас же требуется техническая и аналитическая поддержка. Итак, не взваливая на себя, а именно разделяя с руководителем ответственность за BPM, вы реально можете повысить свой статус в компании.
Сколько стоит «процесс под ключ»? Можно сказать, и слишком дорого, и ничего. Если вы изначально нацелены на то, чтобы ваши процессы были сделаны один раз и навсегда (под ключ), то о каком усовершенствовании может идти речь? Проще запрограммировать их имеющимися средствами и не тратить деньги на BPM-систему. В этом случае вы действительно автоматизируете работу бизнес-процесса. Но вы не сможете им управлять! Для одной конкретной реализации это действительно слишком дорого. В то же время, с точки зрения BPM такой процесс не стоит ничего. Это не BPM.
Правильно ли взваливать BPM на одного человека или даже на одно подразделение? Хорошо отстроенные и управляемые бизнес-процессы – это залог благополучия всего предприятия. А значит и заинтересованность в их развитии тоже распространяется на все его подразделения. Наверняка во многих службах найдутся сотрудники, склонные к аналитическому мышлению и стратегическому предвидению. Создайте команду из нескольких человек, в которую входили бы и аналитики, и ИТ-специалисты, и менеджеры среднего и высшего звена. Организуйте их взаимодействие, совместное принятие решений. Станьте лидером этой команды.
Пройдет ли мода на BPM?
Стоит ли затевать всю эту игру в BPM, если через несколько лет, возможно, не останется даже такой аббревиатуры?
Да, действительно, BPM так быстро меняется и трансформируется, охватывает все большие зоны и управления и автоматизации. Поэтому не прекращаются попытки придумать «самое последнее правильное название». Возможно, что какое-то новое название и приживется – это лишь станет отражением более глубокой формы. Еще пару лет назад BPMS расшифровывали как Business Process Management System, а теперь обоснованно под «S» понимают «Suit». Что это изменило? Только расширило понятие. Можно ожидать, что дальше станут употреблять термин «платформы», поскольку именно в этом направлении ведется активная работа. Но согласитесь, что то, что пришло вместе с BPM – а именно: моделирование + исполнение, бесшовная интеграция, тонкий клиент – это все уже стало входить в норму. Что, изменив название, кто-то откажется от приобретенного?
Можно до бесконечности держаться за старые, проверенные временем, технологии (если кто-то уже забыл, то были времена, когда программисты отказывались принимать объектно-ориентированное программирование, а еще раньше - СУБД). Но рано или поздно новое свое возьмет.
Заключение
Сейчас большинство BPM-вендоров предоставляют бесплатные ознакомительные версии своих продуктов. Так вот среди тех, кто запрашивает ознакомительные версии, примерно 30% составляют студенты, 20% - программисты, 40% - топ-менеджеры и аналитики и 10% - CIO. О чем это говорит?
- Бизнесу нужен BPM (даже если вы об этом не знаете).
- Те, кто еще не достиг высот, видят в BPM перспективу.
- Не все ИТ-директора против BPM.
Сможет ли CIO обойтись без BPM? Возможно – да. Но BPM без CIO обойтись не сможет. И он точно его найдет. А вы?