Плюсы и минусы различных подходов к разработке бизнес-архитектуры
При разработке бизнес-архитектуры можно выделить следующие базовые подходы: "снизу вверх", "снизу вверх" и гибридный.
Подход "снизу вверх" предусматривает глобальный охват проблемы, формирование единого формализованного процесса создания модели бизнес-архитектуры (включая разработку соответствующих методик и определение необходимых стандартов), системный сбор исходной информации для формирования типовых проектных решений.
Положительные черты данного подхода связаны с тем, что с самого начала создается ясное видение существующей ситуации (проблематики) в целом, в обобщенном виде формулируются актуальные бизнес-потребности и проблемы, задаются широкие рамки процесса для возможности эффективной модели бизнес-архитектуры всеми заинтересованными бизнес-подразделениями предприятия, определяется единая методологическая и инструментальная база среды разработки, формируются соответствующие организационные структуры для поддержки процесса разработки и управления. На начальных этапах решается вопрос поддержки проекта топ-менеджментом предприятия практического использования, что упрощает решение вопросов финансирования и взаимодействия с потенциально заинтересованными бизнес-подразделениями предприятия.
Отрицательные стороны использования метода "сверху вниз" связаны с тем, что на начальном этапе требуется проведение большого количества "инфраструктурных" работ, которые должны сформировать методологическую и инструментальную базу для разработки всего предполагаемого множества моделей конкретных бизнес-процессов и их компонент. Данные работы достаточно длительны и формальны, что требует от заказчика дополнительной терпеливости и терпимости в ожидании и понимании того, что же делается по проекту. На фоне такого "напряженного" ожидания вполне возможно, что по ходу проекта может потребоваться от заказчика дополнительное финансирование на обучение персонала по использованию ряда формальных методов, которые необходимы в будущем для разработки моделей конкретных бизнес-процессов.
Характерной особенностью подхода "снизу вверх" является движение от отдельных бизнес-процессов и компонент модели к общей оптимизационной всей модели бизнес-архитектуры.
Данный подход нашел широкое распространение в силу того, что он дает быструю финансовую отдачу, поскольку обеспечивает "старт" с наиболее актуальных проблемных точек. Быстрые успехи повышают авторитет проектной группы и общее доверие к процессу. К положительным моментам метода следует отнести большие возможности по масштабированию и управлению процессом. Это касается и формирования команды проекта, и выбора направлений по бизнес-процессам. По ходу получения результатов для модели оптимизированной бизнес-архитектуры возможно проведение организационных мероприятий по ее претворению в жизнь.
Организации, которым нужно решить с помощью бизнес-архитектуры существенные проблемы, связанные с неэффективностью или большим количеством излишних бизнес-процессов или с наличием перегруженного персонала, технологий, и которым требуется получение видимых результатов от разработки бизнес-архитектуры в кратчайшие сроки, безусловно, должны использовать подход "снизу вверх".
Отрицательные моменты, связанные с использованием подхода "снизу вверх", обусловлены его изначальной ориентированностью на конкретные бизнес-процессы и соответствующие им компоненты. Это существенно понижает уровень универсальности и методологических, и проектных решений при использовании на других направлениях бизнес-процессов, равно как и порождает потенциально сложные и организационные, и технологические проблемы по интегрированию различных моделей бизнес-процессов в единую модель бизнес-архитектуры.
Кроме того, появляется проблема очереди в ожидании бизнес-процессов, не попавших в число приоритетных, по созданию соответствующей среды их проектирования. Существуют высокие риски в отношении того, что формируемая "по ходу" от частных практических задач методология может иметь неоптимальную, если не сказать противоречивую структуру.
Применительно к оперативному и стратегическому решению задач по оптимизации конкретных бизнес-процессов может использоваться гибридный подход, предусматривающий частичное использование как подхода "снизу вверх", так и подхода "сверху вниз". В любом случае, выбранная стратегия моделирования должна отвечать конкретным текущим и перспективным потребностям организации и включать понимание того, что создание модели бизнес-архитектуры – это долговременный процесс изменений.
Глава 4
Современные инструментальные средства моделирования бизнес-процессов. Как выбирать инструментальную среду для бизнес-моделирования
Одним из важнейших этапов решения задачи построения модели бизнес-архитектуры является выбор инструментальной среды.
Для автоматизации моделирования процессов сложился специальный класс программных продуктов. Наиболее известными являются такие продукты, как ARIS, Software Architect, BPWin (новое название – AllFusion Process Modeler), хотя в большом количестве случаев стандартных графических пакетов типа Microsoft Visio, текстового редактора и электронной таблицы бывает достаточно. И в данной книге мы не будем останавливаться на сравнительном анализе этих и других средств и отсылаем читателя к специализированным публикациям.
В данной главе не будет "навязываться" какое-либо конкретное инструментальное средство, а в первую очередь будут определены основные подходы, принципы и рекомендации, которые целесообразно использовать заказчиком и исполнителем при формировании профиля комплекса инструментальных средств моделирования.
К числу обязательной рекомендации для заказчика и исполнителя при осуществлении выбора относится соблюдение принципа учета всех привходящих факторов, связанных с решаемой задачей по созданию модели бизнес-архитектуры предприятия. Огрубленно данные факторы отражают два ключевых момента ("внутренних" и "внешних"):
♦ "внутренние" – потребности и возможности предприятия, связанные с созданием моделей бизнес-архитектуры;
♦ "внешние" – возможности современных инструментальных средств.
Данная глава посвящена всестороннему рассмотрению этих факторов и последующему их учету при принятии окончательных решений по выбору инструментальной среды.
К числу основных "внутренних" факторов, влияющих на выбор заказчиком инструментальной среды моделирования, следует отнести:
♦ производственную необходимость;
♦ бюджетные ограничения;
♦ уровень текущей проработки задач по моделированию и оптимизации;
♦ уровень подготовки персонала;
♦ предыдущие вложения;
♦ характеристики программно-аппаратной платформы и т. д.
По каждому из вышеперечисленных факторов можно дать следующие комментарии.
Производственная необходимость. Несомненно, что постановки задач по моделированию определяют необходимый функционал инструментальной среды. Очевидно, что при всех прочих параметрах не следует с "переплатой" приобретать инструментальную среду с избыточным для решаемой задачи функционалом. Например, если не планируется осуществлять имитационное моделирование, то не следует приобретать данный модуль. Если моделирование нацелено в первую очередь на создание информационных систем, то необходимо подбирать инструментальные средства, сориентированные на эти цели.
Для качественного обоснования производственной необходимости выбираемой конфигурации средств моделирования необходимо:
1) четко сформулировать все "производственные" постановки задач по моделированию;
2) определить под каждую постановку задачи необходимый функционал по моделированию, который должен поддерживаться инструментальной средой моделирования;
3) сопоставить функционал по моделированию возможных к использованию инструментальных средств (модулей инструментальных средств).
Уровень текущей проработки задач по моделированию и оптимизации. Данный фактор в значительной степени связан с вышеописанным фактором "производственной необходимости". Этот фактор определяется следующими ключевыми обстоятельствами:
♦ пройденными (реализованными) в модели бизнес-архитектуры уровнями детализации бизнес-процессов и их базовых компонент;
♦ сформулированными целями по дальнейшей детализации моделей бизнес-процессов и их базовых компонент;
♦ разработанными подходами, включая алгоритмические решения, по оценке состояния бизнес-процессов и их оптимизации.
В определенной степени можно утверждать, что уровень сложности привлекаемых средств моделирования должен соответствовать уровню зрелости (культуры) предприятия, а именно проработки и формализации текущих проблем бизнес-процессов организации.
Очевидно, при отсутствии либо неполноте описательных моделей бизнес-процессов совершенно нет необходимости "гнаться" за функционалом, который должен реализовываться на последующих этапах, например функционально-стоимостной анализ, имитационное моделирование и т. д. В том случае, если нет информации о временных и стоимостных показателях выполнения бизнес-функций и поддерживающих их организационных и технологических ресурсах, то соответственно нет необходимости приобретения дорогостоящих технологий, которые обеспечивают различную логику и алгоритмы обсчета временных, стоимостных и других количественных показателей, равно как и последующей их оптимизации. Аналогично, если не определен и не формализован перечень показателей оценки деятельности, равно как и порядок их получения, то совершенно бессмысленно форсировать закупки программных средств, специализированных на решение только этой задачи.
Бюджетные ограничения. Стоимость инструментальных средств различных производителей может существенно различаться. При этом бюджетные затраты предприятия, связанные с выбором инструментальной среды, будут определяться не только начальными инвестициями на его приобретение, но и последующими затратами на техническую поддержку, обучение персонала, возможную модернизацию программно-аппаратной платформы, потенциальный "апгрейд" и т. д. При этом необходимо отметить, что во многих случаях дистрибьюторы, заинтересованные лишь в продаже программного обеспечения, могут в явном виде не обозначать всех финансовых "обременений", которые могут последовать после этапа покупки инструментального средства. Для точного обсчета финансовой нагрузки могут использоваться специализированные методики, например ТСО. По этой причине общие объемы бюджета предприятия и их соизмеримость с потенциальной финансовой нагрузкой, которая последует за выбором инструментальной среды, могут сыграть главную роль в приятии окончательного решения.
Уровень подготовки персонала. Данный фактор чаще всего забывается заказчиком. Особенно критичным этот фактор является для тех предприятий, которые рассчитывают на самостоятельное решение задач либо по разработке, либо по поддержке модели бизнес-архитектуры. При всей дружелюбности пользовательского интерфейса, средств разработки требуются специальная и общесистемная подготовки для исполнителей работ по моделированию, равно как и проведение обучения пользователей.
Как правило, чем шире возможности инструментальной среды, тем выше выдвигаются требования к техническому персоналу и пользователем. Соответственно, более длительными оказываются сроки подготовки. Во многих случаях обеспечение адекватности компетенции персонала организации сложности инструментальной среды моделирования не может быть решено в приемлемые сроки только проведением обучения. Вполне возможно, что потребуется более радикальное решение проблемы недостаточного уровня технологической компетенции организации, а именно наем уже подготовленных квалифицированных специалистов.
Понятно, что при наличии существенных финансовых ограничений на обучение, сжатых сроков внедрения системы при значительной длительности процесса обучения, организационных сложностей с подбором специалистов либо расширением штатов "человеческая" проблема может стать основным препятствием на пути внедрения нужной для организации инструментальной среды моделирования.
В целом необходимо отметить, что игнорирование человеческого фактора может либо на начальных этапах, либо в "отложенном" режиме создать проблемы по созданию и эффективному использованию модели бизнес-архитектуры предприятия. Недостаточный уровень знания общесистемных и прикладных возможностей среды моделирования породит неустойчивость работы системы, раздражение, боязнь и как следствие отторжение конечными пользователями предлагаемого программного обеспечения.
Предыдущие вложения. Вполне возможна ситуация, когда на предприятии уже проводились работы по моделированию бизнес-процессов и, соответственно, были осуществлены определенные вложения. Данные вложения могут быть связаны с закупками программного обеспечения и технических средств, обучением технического персонала, пользователей, оплатой технической поддержки, созданием специальных приложений и т. д. Не менее значимыми, чем финансовые затраты, являются обстоятельства, связанные с накоплением значительного количества информации ("знаний") в форматах ранее использованной инструментальной среды. В том случае, если данные форматы являются "автономными", потенциальный переход в новую инструментальную среду может потребовать разработки специальных средств преобразования. Другой важной составляющей проблемы трансформации знаний бизнес-процессов в иную инструментальную среду является "ломка" привычек пользователей, связанных с применением ставших "традиционными" в организации форм представления информации по бизнес-процессам.
В зависимости от глубины и значимости технологической и "культурной" составляющей истории формализации бизнес-процессов на предприятии должны приниматься взвешенные решения по выбору новой инструментальной среды моделирования. В том случае, если предыдущие вложения очень значительные, то вполне возможно, что организации следует "смириться" с несовершенством используемых технологий и отказом от перехода на принципиально новую инструментальную платформу. В случае если существует целесообразность миграции на другую платформу, то в число ключевых параметров по выбору новой платформы при наличии нескольких альтернатив должны попасть следующие условия к кандидату на замену:
♦ уровень ее совместимости со старой средой моделирования;
♦ уровень "похожести" интерфейса с заменяемой платформой;
♦ схожесть требований к квалификации технического персонала и конечных пользователей с заменяемой платформой;
♦ отсутствие необходимости модернизации общесистемной программно-аппаратной платформы;
♦ возможность использования существующей инфраструктуры технической поддержки и обучения.
Характеристики программно-аппаратной платформы. Чем сложнее инструментальная среда моделирования, тем оно "тяжелее" с точки зрения требования к общесистемной программно-аппаратной платформе. При выборе инструментальной среды модели необходимо оценить следующие вопросы:
♦ требования к технической платформе;
♦ требования к общесистемному программному обеспечению;
♦ требования к телекоммуникационному обеспечению;
♦ возможности по обеспечению информационной безопасности;
♦ количество мест установки пользовательских приложений.
В том случае если текущая конфигурация программно-аппаратной платформы предприятия не может обеспечить установку инструментальной среды на планируемом количестве пользовательских мест, то предприятие должно принимать управленческое решение в отношении качественно-количественной модернизации своего ИТ-парка. Соответственно, при наличии в компании финансовых и организационных ограничений на модернизацию программно-аппаратной платформы ИТ-парк может стать основным препятствием на пути выбора требуемой инструментальной среды моделирования.
В настоящее время у многих заказчиков существует устоявшееся представление, что для построения модели бизнес-архитектуры предприятия достаточно использования какого-то одного инструментального средства. Вместе с тем это далеко не так. Специфичность областей и способов моделирования обусловливало появление линейки программных средств поддержки процесса моделирования.
В ряде случаев могут существовать такие постановки задач, которые могут потребовать для своей реализации не одного, а нескольких программных средств поддержки процесса моделирования. Подбор нескольких программных средств определяется оптимальностью решения составных частей поставленной задачи.
В частности, если заказчиком ставится задача "сквозного" моделирования с последующей автоматизацией тех или иных функций, то вполне очевидно, что при наличии двух объектов моделирования (бизнес-логики деятельности организации и функционирования информационной системы) целесообразно использовать как минимум два класса средств:
♦ программные средства моделирования (формализации), нацеленные на общее описание бизнес-процессов;
♦ программные средства моделирования (формализации), нацеленные на разработку автоматизированных информационных систем.
Аналогичная ситуация сложилась и при необходимости использования нескольких разнопрофильных средств моделирования при исследовании различных сторон одного и того же объекта. Например, при постановке задачи анализа структуры и поведенческой (динамической) составляющей моделируемого объекта должно быть предусмотрено использование как минимум двух классов программных средств (модулей):
♦ средств формализованного описания статической структуры бизнес-процесса;
♦ средств динамического анализа (имитационного моделирования).
Поэтому правильной для заказчика является постановка задачи не приобретения одного инструментария, а формирования единой корпоративной среды моделирования, предусматривающей использование нескольких программных средств (профиля средств) моделирования бизнес-архитектуры.
Принципиальное значение для определения архитектуры среды моделирования бизнес-процессов имеет общая стратегия предприятия в части создания прикладных программных средств. В общем случае существуют две ключевые стратегии в части создания прикладного ПО:
♦ опора на заказные разработки;