Литература:

• Статьи
• Обзоры
• Форумы
• Стандарты
• Книги
• Авторы

Автор: Фил Гилберт, Lombardi Software.

Оригинал статьи: Phil Gilbert, On BPM Governance, The Five Charters of BPM Governance.

Аннотация: Существующие в вашей компании процедуры руководства проектами предназначены для защиты от риска провала больших проектов, а также для того, чтобы отсеивать теневые проекты ИТ. Проекты BPM невелики, и на уровне бизнеса они бывают очень похожи на теневые ИТ-проекты, поэтому существующие процедурные требования выстраиваются против их утверждения. Мы должны изменить это положение, чтобы в полном масштабе реализовать гибкость, которую обещает BPM. Я предлагаю пять Хартий руководства BPM. Они будут свободно доступны в соответствии с открытым исходным кодом Creative Commons License. До релиза они будут обсуждаться в серии публикаций на блоге.

(Примечание переводчика: в оригинальном тексте автор использует термин «Governance», понимая под ним систему надзора и руководства проектами BPM. В переводе всюду используется термин «руководство».)

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

Позвольте мне задать вам два вопроса:

1. Через что вам придется пройти в вашей организации для утверждения 20 проектов по $500 000?
2. Через что вам придется пройти в вашей организации для утверждения одного проекта ценой $10 00 000?

Цена одинакова, но бьюсь об заклад, первый вариант в 10-15 раз тяжелее.

Мы просто не готовы управлять BPM.

Избежать крупных неприятностей

В прошлом общими для всех стратегических ИТ-проектов были риски, которые мы в итоге стали воспринимать как нормальные:

• Дорогостоящие
• Длительные
• Не отвечающие ожиданиям при сдаче

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

Кстати, это относится не только к заказным приложениям, разработанным много лет назад. Кто не слышал о внедрениях SAP, проектах IBM и проектах Oracle, в которых все пошло чудовищно неправильно? Действительно, разве нарушение сроков, бюджета и требований для подобных вещей не норма?

Избежать мелких неприятностей

Проекты BPM принципиально отличаются от типичных дорогих и длительных проектов разработки. Поскольку в число базовых понятий BPM входит представление о множестве сравнительно небольших, своевременно выполняемых и дающих быструю отдачу проектов, в этом легко усмотреть анархию; тысячу вышедших из-под контроля проектов «теневого ИТ», создающих новый хаос по образцу Lotus Notes или Access/Excel. Примерно раз в неделю кто-то отводит меня в сторону и говорит шепотом, что не уверен в масштабируемости BPM, они «не могут позволить пользователям потеряться в еще одном Access, Excel или Notes». И они правы: кому нужна такая головная боль? Не станет ли BPM случайным набором точечных решений, некоторые из которых дают эффект, многие эффекта не дают и ни один из которых не становится частью единого целого, которое можно эффективно поддерживать и обновлять в соответствии с целями вашей компании.

Избежать любых неприятностей

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

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

• Закупки по проекту обходятся дорого
• Обеспечение ИТ-оборудованием является затратным и медленным
• Выделение ресурсов для управления изменениями в бизнесе базируется на старой модели массового обучения пользователей в течение длительного периода внедрения.

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

• Сложно утвердить проект
• Затратно добиться выделения разработчика
• Черт, невозможно даже добиться от снабженца, чтобы он нашел для вас время в своем расписании

Это просто смешно. Мы постоянно работаем с компаниями, в которых сотни людей заняты в масштабных проектах, которые дадут отдачу через кварталы, если не годы. Но едва ли не сложнее найти трех человек для работы в течение 4 месяцев в проекте BPM, который даст работающее процессное приложение.

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

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

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

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

Чтобы получить новый результат, надо по-новому мыслить

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

Чтобы получить эти новые результаты, нам нужна новая модель.

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

Парадоксально, не правда ли?

Основы BPM

Приступая к BPM, где все проекты небольшие - два или три человека с полной занятостью – и где время до развертывания такое короткое - от 90 до 120 дней это реальность - вы просто не вписываетесь в стоимость согласования проекта. Я имею в виду, что вы можете, буквально, потратить на утверждение проекта столько же времени, что и на выполнение самого проекта.

Программа BPM принципиально отличается. Я должен был бы сказать, «отличается принципиально, если делается правильно». BPM – это программа, а не проект. Это куча проектов, может быть, сотни, но, безусловно, несколько десятков проектов. Все нацелены на несколько – может 2 или 3 – цели верхнего уровня. Каждый из которых добавляет ценности бизнесу каждые 90 дней или около того. Это совершенно новый стиль разработки приложений для внутреннего использования, поскольку она является противоположностью почти всем когда-либо разработанным централизованным ИТ-приложениям.

 

ERP/традиционная разработка приложений	BPM
Один длительный проект	десятки или сотни коротких проектов
«длинные» сквозные процессы, внедряемые целиком	короткие фрагменты, полученные декомпозицией, внедряемые асинхронно
Внедрение большим скачком	точечное внедрение
Множество пользователей в итоге переходят на одну «версию»	Группы пользователей небольшого или среднего размера добавляются с каждой итерацией
Большие проектные команды (зачастую исчисляемые сотнями)	Небольшие проектные команды (в пределах десяти)
Бюджет проекта измеряется миллионами $	Бюджет проекта измеряется сотнями тысяч $

BPM построен на многих из прагматических принципов «теневой» разработки приложений:

• На 80% лучше чем сегодня – это достаточно хорошо, остальное мы получим в версии 2
• Высокая степень участия бизнеса в разработке приложений
• Небольшие группы, небольшие инвестиции, быстрая отдача
• Небольшие, казалось бы случайные куски, образующие сеть управляемых процессов, которая строится буквально снизу вверх

Но с качествами, необходимых для масштабируемости:

• Централизованная, разделяемая инфраструктура
• Развертывается и поддерживается сверху до низу с помощью лучших практик и процедур ИТ
• Безопасные, усиленные приложения высокой готовности.

Открытое приглашение к участию

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

Я буду свободно распространять эти Хартии. Я хочу, чтобы BPM сообщество в целом, независимо от используемого инструментария и партнерских связей, вело диалог и вносило вклад в эти Уставы. Они не привязаны к продавцу или конкретному инструментарию. Они будут свободно доступны для использования и модификации в соответствии с лицензией Creative Commons License. Они будут разрабатываться на вики, чтобы мы все могли участвовать в их развитии.

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

Пять Хартий руководства BPM

Аннотация: Вторая из семи публикаций на тему руководства BPM. Никогда прежде не делалось ничего подобного BPM. Сегодня мы являемся заложниками той самой системы, которая позволила нам дорасти до этого уровня. Нам необходимо сбалансировать децентрализованную производительность, которую делает возможной сегодняшняя технология, при этом по-прежнему удерживая масштаб централизации, который дали вчерашние технологии. BPM – это набор небольших, организованных снизу-вверх реализаций целей, организованных сверху-вниз. Вертикальная интеграция показателей производительности процессов вдоль горизонтально интегрированных реализаций. Чтобы это сделать BPM связан с бизнес-пользователями теснее, чем любая технология разработки в истории. Необходима новая модель для руководства этими проектами. Пять Хартий руководства BPM предложены и будут свободно распространяться в соответствии с лицензией Creative Commons. Эта публикация представляет их и дает краткое описание назначения каждого. В последующих публикациях каждая из пяти будет рассмотрена более подробно.

BPM не такой

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

BPM намерен разорвать этот цикл, меняя основные лежащие в его основе предположения.

• «Сеть» реализаций процессных приложений снизу-вверх
• Координированная стратегия, задающая роадмап реализаций
• Основная психологическая модель – продукт, ограниченный временем против продукта на основе функций
• Множество итераций (версий) каждого процессного приложения
• Способность использовать эти итерации в бизнесе (изменение приложений плюс растущее сообщество пользователей)
• Высокая степень повторного использования компонент приложений
• Постоянное участие бизнес-пользователей в процессе разработки
• Постоянное участие бизнес-пользователей в процессе развертывания

Элементы нового руководства

У нас просто отсутствуют модели руководства, на которые мы могли бы полагаться, чтобы:

1. Установить, каким образом это новый тип платформы разделяется между заинтересованными лицами; кто может играть в песочнице BPM
2. Обеспечить ясность в том, на какие метрики нацелен проект BPM, и каковы критерии успеха; создать структуру, обеспечивающую следование данного проекта целям программы, зафиксированном в уставе; следование друг другу проектов, выполняемых снизу-вверх
3. Обеспечить масштабируемый механизм для инициирования и одобрения бизнес-обоснований для проектов BPM; определить финансовые и иные требования для включения проекта в программу
4. Обеспечить документированный способ, которым проекты BPM включаются в роадмап развития интерфейсов доступа к основным системам; определить шкалу зрелости интерфейсов, соответствующую требованиям проекта BPM
5. Определить каким образом будет поддерживаться общая инфраструктура BPM и как соответствующие затраты будут относиться на различные процессы, находящиеся под нашим руководством

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

Руководство. Что это еще за чертовщина?

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

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

Первое, что мы должны сделать, разбираясь с руководством – это сделать его реальным. Материальным. Руководство не является каким-то абстрактным понятием, хотя оно и включает абстрактные понятия. Например, Конституция США является конкретным (пусть даже иногда непостижимым) руководящим документом. Поэтому, хотя нам нужна общая перспектива BPM (Декларация Независимости, если хотите), должен быть набор действенных правил, которые можно произнести и которым можно следовать. Эти правила помогают определить:

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

Пять Хартий руководства BPM

1. Хартия совместного использования платформы BPM
2. Хартия демократичного BPM
3. Хартия бюджетирования и прозрачности проектов BPM
4. Хартия «конфликтных ситуаций» BPM
5. Хартия инвестиций в платформу BPM

В следующих пяти записях на блоге я буду обсуждать каждый из них. Впоследствии, я сделаю эти Хартии доступными под лицензией Creative Commons. Я также создам веб-сайт, на котором сообщество сможет изменять и улучшать созданные мною скелеты документов. У меня нет какого-то сложившегося представления о том, как это должно быть сделано. Я только знаю, что мы должны создать такой каркас, и чем быстрее мы это сделаем, тем лучше. Компании во всем мире сражаются за то, чтобы преобразовать проекты BPM в масштабируемые программы BPM. Но на этом пути есть всего несколько указателей, и еще меньше есть компаний, которые реально достигли полномасштабного представления об этом.

Краткое описание пяти Хартий

Хартия совместного использования платформы BPM

Сегодня слишком часто оказывается, что люди или небольшие группы, выполнившие первый проект BPM, становятся «хранителями огня», если можно так выразиться. Эти люди становятся привратниками - неважно хотят они этого или нет, они зажаты рамками собственных возможностей влияния в организации и ограниченности ресурсов. Кроме того, в компании любого размера эти команды – это не те команды, которые лучше других разбираются в бизнесе. По той естественной причине, что эти команды развивают передовую технологию, или по крайней мере они первыми стали использовать новую технологии, они вероятно находятся не в лучшем положении для того, чтобы развить свой успех в масштабах организации.

То, как платформа BPM разделяется между проектами, и то, как формируется роадмап проектов, должно иметь больший охват, чем лицо (лица), достигшие одного или двух успехов. Для этого должна быть надлежащая организация.

Кроме того, поскольку роадмап BPM планируется сверху-вниз, но реализуется снизу-вверх, необходимо создать новую руководящую группу из руководителей бизнес–подразделений, независимую от навыков, необходимых для реализации снизу-вверх, которые могут культивироваться, скажем, в Центре повышения квалификации (ЦПК). ЦПК должен стать одним из тактических результатов наличия Хартии совместного использования платформы BPM. ЦПК – это тактическое средство реализации, а не стратегический орган. Настоящий Устав определяет принципы совместного использования платформы и органы, ответственные за обеспечение стратегической согласованности проектов BPM, а также роадмап BPM.

Хартия демократичного BPM

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

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

Хартия бюджетирования и прозрачности проектов BPM

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

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

Данная Хартия разъясняет эти требования и предоставляет трибуну для понимания метрик сквозь бизнес-подразделения.

Хартия «конфликтных ситуаций» BPM

BPM обитает не в чистом поле и не в отрыве от систем, которые 40 лет развивает ваша компания. Тогда как же они сосуществуют? Как BPM стимулирует ваши инициативы SOA (или этого не происходит)? Как вы согласуете BPM-роадмап, оперирующий неделями, с усилиями по обновлению и консолидацию систем, которые на законных основаниях длятся кварталами и годами? Нам необходимо создать мысленное представление о том, как согласовывать эти усилия друг с другом. Данная Хартия документирует требования к согласованию роадмапов и предлагает конкретные механизмы для своевременного и экономически эффективного достижения всех технологических роадмапов: BPM, обновления и консолидации.

Хартия инвестиций в платформу BPM

Является ли BPM совместно используемой службой? Учитываете ли вы затраты исходя из числа процессных приложений, которые, как вы считаете, будут созданы в течение трех лет? Или только в этом году? А как вы учитываете поддержку платформой множества процессных приложений. По количеству пользователей? С фиксированной платой за каждого? Как насчет стоимости лицензий?

И как мы поддерживаем нашу инфраструктуру? Как насчет апгрейдов? И что произойдет, если апгрейд инфраструктуры затронет одно из существующих процессных приложений BPM? Кто заплатит?

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

В следующем выпуске – подробное рассмотрение Хартии совместного использования платформы BPM.

Примечание: источник моего вдохновения для пяти Хартий

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

1. Хартия доходов от природных ресурсов
2. Хартия демократии: свобода слова, ТВ, радио
3. Хартия прозрачности бюджета: сверху вниз, снизу вверх, коллегиального рассмотрения - предварительное, задним числом
4. Хартия пост-конфликтных ситуаций; стандарты после развертывания?
5. Хартия инвестиций

Я прочел ее после того, как я увидел речь д-ра Кольера на TED.com весной. Я уже думал о руководстве BPM в течение некоторого времени, а точнее с прошлого декабря, но понимание что же конкретно нужно не выкристаллизовывалось, пока я не увидел выступление Кольера, а потом прочел книгу.

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

Комментарии