Так ли уж близки корпоративная архитектура и бизнес-процессы?

capabilityРаз уж мы в предыдущей заметке BABOK Guide v3 techniques map заговорили о новых техниках бизнес-анализа, то стоит о некоторых из них написать немного подробней. Начнем с бизнес-архитектуры, которая представлена теперь в своде знаний отдельной перспективой (раздел 11.4) и парой новых техник Business Capability Analysis (раздел 10.6) и Business Model Canvas (раздел 10.8). О второй технике я немного писал в заметке Чему ИТ может научить бизнес. Пара замечаний о Product Development и сейчас не стану останавливаться на ней подробно. А вот про business capability стоит поговорить. Тем более, что есть интересный нюанс.

Наряду с перспективой бизнес архитектура в BABOK Guide v3 появилась отдельные перспективы Business Intellegence (раздел 11.2) и Business Process Management (раздел 11.5). Казалось бы, управление бизнес-процессами, наряду со стратегией, является неотъемлемой частью архитектуры бизнеса.  На всех картинках нарисовано именно так. Описание организационной структуры и процессов предусмотрено всеми архитектурными фреймвоками, отражено в нотации Archimate и представлено в инструментах моделирования корпоративной архитектуры. Однако на практике подходы к описанию бизнес-архитектуры уже несколько лет выглядят немного иначе. Архитекторы говорят не о бизнес-процессах, а о business capabilities. Понятие capability непросто перевести и еще труднее объяснить. Англоязычная статья в Википедии Capability management in business довольно объемна и скорее отвечает на вопрос почему capability не следует  отождествлять с процессом или компетенцией. Тем не менее, большинство корпоративных архитекторов сейчас оперируют именно этим понятием, а дискуссии типа Why Business Capabilities are not in the Zachman Framework завершились уже лет пять назад. Я не стану пытаться перевести термин capability (возможность, способность, организационная компетенция?) и даже не попытаюсь его определить (см. Business Capability Definition или Defining the Business Capability – A Cheat Sheet), а сконцентрируюсь на двух моментах.

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

Второй момент перекликается с широко известной Capability Maturity Model и заключается в том, что capability может быть развита в разной степени. В CMM речь идет о степени зрелости процесса, но ровно те же самые рассуждения легко применить и к компетенциям, ресурсами и пр. Никто не заставляет вас сразу иметь оптимизирующийся процесс пятого уровня. Вы можете решить для себя, что управляемого или даже установленного уровня вполне достаточно.

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

В ближайшее время постараюсь написать об использовании данного подхода в ИТ. Думаю тема techology (IT) capabilities непременно найдет своего [по]читателя.

Так ли уж близки корпоративная архитектура и бизнес-процессы?: 13 комментариев

  1. Mainly agree. Just a small correction: not enterprise architects but business architects (primarily followers of BIZBOOK). My analysis is in http://improving-bpm-systems.blogspot.ch/2015/01/common-understanding-of-bizarch.html

    Concerning “двух моментах”.
    1. It can be addressed by the view of an enterprise as a system of processes (see http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-as-system-of-processes.html ) and inclusion of all processes involved (see http://improving-bpm-systems.blogspot.ch/2015/02/iceberg-of-processes-within-enterprise.html )

    2. At present, capability consultants provide qualitative evaluations of capabilities. To provide quantitative evaluations it is necessary to have executable model of an enterprise which is based on its processes.

    Thanks,
    AS

  2. Введение и стандартизация Модели Возможностей (см. ISO/IEC 15504 или ГОСТ Р ИСО-МЭК 15504) в качестве альтернативного взгляда на характеристики процессов и их атрибутов взамен Модели Зрелости (см. CMMI или COBIT 4.1) привело к проникновению данного подхода во многие сопряженные сферы знаний. Так COBIT 5 базируется (включает) именно на Модели Возможностей ISO/IEC 15504.

    Автор прав, что данный подход позволяет комплексно оценивать возможность перехода (изменения) на более высокий и/или эффективный уровень организации бизнеса, но объектом оценки являются все же процессы и другие факторы. Так, например, COBIT 5 определяет семь видов факторов влияния на бизнес: – Принципы, политики и подходы; – Процессы; – Организационная структура; – Культура, этика и поведение; – Информация; – Услуги, инфраструктура и приложения; – Люди, навыки и компетенции

    Модель Возможностей, используемая в TOGAF 9.1, рассматривает не факторы влияния, а факторы готовности, их оценку по степени зрелости (Модель Зрелости) в начальном (as is) и конечном (to be) состоянии, причем оценка конечного состояния и потребности его достижения формируется на уровне видения. Далее производится оценка рейтингов всех 12 (BTEP) факторов готовности по уровню срочности (до, во время, после изменений), оценка состояния готовности по этим факторам (низкая, посредственная, удовлетворительная, хорошая, высокая) и степени сложности изменений (действий не требуется, легко, умеренно или трудно). Затем по всем факторам готовности проводится оценка рисков и действий по достижению целевого состояния. Учет всех перечисленных оценок и дает совокупную модель возможностей, которая позволяет провести планирование инкрементов изменений. Причем, формально, каждое инкрементальное состояние архитектуры будет представлено в виде бизнес архитектуры (в т.ч. бизнес процессов), архитектуры данных, прикладной и технологической архитектуры.

    Обновления COBIT и BABOK, включающие в себя, в том числе, и переход от модели зрелости к модели возможностей, создали некоторые разночтения с TOGAF 9.1, который подразумевает интеграцию в себе ключевых понятий и методов целого ряда прикладных отраслей знаний и стандартов, однако они не являются критичными на практике, где само внедрение этих методологий зависит от возможностей и потребностей бизнеса.
    В любом случае, бизнес процессы, как понятие, присутствуют в любой из упомянутых методологий, хотя и не рассматриваются как самоцель или как основной фактор, определяющий бизнес.

    1. “Модель Возможностей, используемая в TOGAF 9.1, рассматривает не факторы влияния, а факторы готовности…” – обращая слишком много внимания на теорию, мы очень часто забываем о практике.
      Заказчику наплевать на факторы влияния/готовности, равно как и на Возможности (использую этот термин, чтобы оставаться в рамках терминологии автора), Программисту тоже наплевать на указанное, и даже (о, божемой) Руководителю проектов наплевать. Тем, кто делает системы своими руками все это кажется высокопарной ерундой, и, признаемся себе, ей и является. Под сугубо теоретическое понятие Возможности следует подвести физическое понятие – набора функции/гиперфункции/да хоть квазифункции как начала и части системы как окончания. Тогда Возможность становится кому-то нужна и понятна участникам проекта.

      1. Термин “гиперфункции” мне нравится. В принципе, термины capability и функция довольно близки, только функция, как способность производить результат (outcome). Заказчику часто, действительно, на все наплевать, по крайней мере пока он может внятно ответить на вопрос что и зачем он делает. И это не тема бизнес-процессов, отвечающих на вопрос “как” и не тема информационных систем. А вот тезис о том, что надо системы делать, а все остальное высокопарная ерунда я не разделяю. Уже и так наделали столько систем, что ставить некуда. Многие организации живут на свалке из программного обеспечения, но по привычке заказывают все новые и новые системы

        1. Возможно я не точно выразила мысль. Проектирование, планирование, осмысление необходимо на Предприятии. Это – бесспорно. За это мне как архитектору и платят зарплату. Но важно не забывать, что цель проектирования – создание, разработка, а не жонглирование терминами в высокоинтеллектуальных беседах. Поэтому, я люблю приземлять методологии, и не люблю долгие теоретические выкладки без практических примеров.
          В конечном итоге и Возможности, и Функции, и Процессы ложаться, например, в ADOit, и тут важно всегда иметь ввиду под этими терминами конкретные субъекты проектирования.

          1. Неожиданный поворот дискуссии, точнее «приземление» в лужу. Прямо как по анекдоту про милиционера и яблоко на дереве – «А что тут думать – трясти надо!». Изначально рассматривался достаточно практический вопрос, который может быть отнесен как к Заказчику (бизнесу), так и к Исполнителю (ИТ-компании/подразделению).
            Конкретная ситуация: после внедрения Решение не используется в должной мере, не работает и, в конце концов, прекращает свое существование. Почему? Могло ли быть иначе? Что делать?
            Другая ситуация: исполнитель берется за создание ИТ-решения, но результат не достигнут, сроки нарушены, деньги потрачены. Почему? Могло ли быть иначе? Что делать?
            Если внимательно посмотреть в том же ADOit, то там и Процессы, и Функции, и другие Артефакты могут иметь атрибуты, в том числе связанные, например, с реализуемостью. Атрибутизация и ранжирование всех артефактов проектирования, в том числе бейзлайнинг (планирование реализации), вопрос не просто из разряда RTFM (см. Wikipedia), но и требует определенных теоретических знаний и практических навыков.
            А если всем и на все наплевать, то зачем результат!?! «Пилите, Шура, пилите…». Или все же стоит подумать ЧТО и КАК делать?… ;о)

    2. Александр, я не вижу кнопки “Ответить” на вашем нижнем комментарии, потому отвечаю на этот.
      Если вы еще раз прочтете мой комментарий, то вероятно вы увидите, что я не отрицаю необходимость обладания теоретическими знаниями, но настаиваю на необходимости привязки теоретических знаний к практическим. Я не вижу смысла в обладании теоретическими знаниями, которые не имеют применимости. Проще говоря: оставаясь в теме заглавной статьи, допустим, я не знаю что такое Возможность теоретически, но не имею представления, что это такое практически (допустим, не могу найти аналога в практической плоскости), в этом случае для меня знание о Возможности не представляет практической ценности. (Естественно, что я уже знаю что такое Возможности в реальном мире, приняла для себя некие установки).

      Теперь немного по вашему комментарию (спасибо, что дискутируете со мной, это очень интересно).
      “Конкретная ситуация: после внедрения Решение не используется в должной мере, не работает и, в конце концов, прекращает свое существование. Почему? Могло ли быть иначе? Что делать?
      Другая ситуация: исполнитель берется за создание ИТ-решения, но результат не достигнут, сроки нарушены, деньги потрачены. Почему? Могло ли быть иначе? Что делать?”
      Это уже тема немного другого разговора, тем не менее, она тоже интересная. Указанные вопросы возникают в задачах архитектора, если это архитектор заказчика или архитектор системы, которая получила развитие в виде второго контракта после внедрения на приличную сумму денег, то есть не контракт поддержки.
      Если этот архитектор – архитектор интегратора, то идеология его работодателя следующая “за работу любого сотрудника должно быть уплачено; если за работу сотрудника не уплачено, сотрудник не должен исполнять работу”. То есть, если нет денег/времени архитектор интегратора не думает над проблемой 1 никогда, а над проблемой 2 только по просьбе руководителя проектов. (Конечно, архитектор интегратора может подумать над проблемами 1 и 2 для личного развития в свое свободное от работы и учебы время). К сожалению, я никогда не работала архитектором заказчика, поэтому моя работа крутится вокруг первых фаз TOGAF, да еще с учетом того ограничения, что я на старте проектирования никогда не знаю весь ландшафт и наследие.
      “Атрибутизация и ранжирование всех артефактов проектирования, в том числе бейзлайнинг (планирование реализации)” мне по этой причине не доступно, так как они не будут исчерпывающими и объективными в любом случае.

      Здесь хочется затронуть еще одну тему – было бы классно, если бы автор сего блога возбудил по ней дискуссию. Тема провокационная, но я хотела бы почитать мнения.
      Кому из работодателей вообще нужна методология? Любая – хоть сбора требований, хоть проектирования архитектуры.
      К сожалению, я постоянно сталкиваюсь с тем, что работодатель и, как следствие, руководители проектов, совершенно не заинтересованы в какой-либо методологии чего-либо. Считают это бесполезной тратой времени и тп.
      И таким образом получается, что в работодателе-интеграторе из 10 архитекторов (условно) 2 знают и пользуются методологией и средствами проектирования, а остальные 8 смотрят на первых двух, как на идиотов. С другой стороны, 2 самообученных смотрят на документы (как записанный результат проектирования) остальных 8 как на “детский сад” и “кустарное производство”, скорбно вздыхая, но ничего не могут с этим поделать. Внимание, вопрос: А как у вас? Как у ваших работодателей и ваших коллег-архитекторов и аналитиков обстоят дела?
      Должен ли архитектор знать методологию или достаточно иметь опыт построения систем и хорошо знать линейки продуктов вендоров и техническую составляющую?

      Вы не представляете, как мне приятно общаться на эти темы, в связи с тем, что они все еще имеют малое распространение. Спасибо.

      1. Алёна, чтоб дискуссия получилась надо сделать интересный материал, например, в форме интервью(обмена мнениями), опроса, пару картинок нарисовать, в соц.сетях попиарить и т.п. Я думаю, что востребованность методологии определяется задачей, для решения которой она привлекается. Когда мне надо было за короткий срок обеспечить пару десятков проектов архитектурой и архитекторами, которые бы её создавали, потребность в методологии проявилась вполне отчетливо.

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

        В общем, предлагаю Вам сделать совместное сообщение на эту тему – попереписываемся немного по e-mail, а затем выложим получившийся материал в блог.

      2. Алена,
        Статистика, которую вы привели не сильно радует, но в среднем по отечественному рынку ситуация не лучше, хотя и меняется к лучшему. Меняется, в ом числе, благодаря «теоретикам», которые продвигают знания в массы и развивают эти знания и методологии. Я, как практик, ценю их работу, т.к. она мне нужна сугубо для практического использования. Заказчику нужен не функционал системы от вендора, а решение, которое удовлетворит его потребности, будет у него работать и даст требуемый эффект. В этом случае и внутреннему ИТ и исполнителю (подрядчику) приходится напрягаться и проводить нормальный анализ требований, планировать архитектуру решений, управлять качеством и надежностью.
        К сожалению, подобных заказчиков тоже пока лишь 20%, а 80% удовлетворяются внедрением функционала систем и дальше сами с этим пытаются как-то разобраться. Спрос порождает предложение.

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *