|
Календарь мероприятий
ноябрь  2024
Пн |
Вт |
Ср |
Чт |
Пт |
Сб |
Вс |
| | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | |
показать все 
Новости партнеров
Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость
Читать далее
RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза
Читать далее
Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium
Читать далее
ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве
Читать далее
Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов
Читать далее
показать все
Статьи
ИИ: маршрут не построен, но уже проектируется
Читать далее
Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»
Читать далее
Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»
Читать далее
Технологический ИИ-арсенал
Читать далее
Чем страшен ИИ, и с чем его едят
Читать далее
Взгляд в перспективу: что будет двигать отрасль информационной безопасности
Читать далее
5 способов повысить безопасность электронной подписи
Читать далее
Как искусственный интеллект изменит экономику
Читать далее
Неочевидный САПР: выход ПО за рамки конструкторской деятельности
Читать далее
Скоро некому будет делать сайты и заниматься версткой
Читать далее
показать все
|
ИТ-процессы и архитектура
Главная /
Архив номеров / 2017 / Выпуск №03 (66) / ИТ-процессы и архитектура
Рубрика:
ИТ-процессы
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Марина Аншина, президент фонда ФОСТАС, председатель Комитета по стандартам Российского Союза ИТ-директоров
ИТ-процессы и архитектура
Как же без архитектуры? Хотя мы уже встречались с классификацией процессов по архитектурным слоям, этой теме, несомненно, стоит уделить больше внимания. Хотя бы потому, что, сколько ни говорят про архитектуру предприятия (далее – АП) ее приверженцы, не приживается этот термин и все с ним связанное в нашей стране. Видимо, либо «архитектофилов» слишком мало, либо говорят они недостаточно громко. Вот уже и Союз Архитекторов создали! Надеюсь, что ему удастся сделать архитектурную деятельность более популярной
 Заранее извиняюсь перед теми, кто читал мои статьи и книги и уже неоднократно сталкивался с определениями АП и возникающими по поводу нее мыслями. Но ведь кто-то же будет читать об этом в первый раз, и о них я тоже обязана подумать. С другой стороны, повторение – мать чего-то там хорошего. И с третьей – очень важен момент, когда мысль повторно попадает в твою голову. Ты начинаешь воспринимать ее совершенно по-другому, без вполне понятного скепсиса, с которым большинство людей относится ко всему новому. Она наконец приживается в твоем мировоззрении и становится привычной частью твоего сознания.
Термин «архитектура», который в массовом сознании относится к строительству, может быть применен к любой системе. И в этом случае, нимало не противореча своему первоначальному смыслу, охватывает состав системы, взаимодействие ее частей, а также ее развитие. Даже те, кто уже давно успешно ввел АП в свой лексикон, зачастую страдают неким статическим синдромом, который заставляет их относиться к АП как к чему-то столь же неизменному и постоянному, как колонны античных сооружений, сохранившиеся спрошлых эпох.
Как и все на свете, это можно объяснить. Рискну предложить свои размышления по этому поводу. Здания долгие годы были, возможно, одной из самых устойчивых систем вокружающем нас мире. Их архитектуру обычно кардинально не меняли, ограничиваясь пристройками и надстройками. В большинстве случаев существенное изменение архитектуры дома просто невозможно или очень дорого – намного проще его разрушить и построить на его месте новый. Более гибкие варианты зданий возникают только сейчас благодаря появлению новых материалов и других технических возможностей. Да и то потихоньку.
Если же говорить об архитектуре других систем, то зачастую она меняется так быстро, что возникает обманчивое впечатление, будто ее и вовсе не существует. Однако оно именно обманчиво. Архитектурой обладают все системы, просто одни более устойчивы, а другие менее. И нельзя сказать, что анализ архитектуры для первых важнее, чем для вторых. Совсем наоборот. Ведь очевидно, что чем сложнее и изменяемей система, тем важнее для нее архитектурный подход. Потому что, не учитывая взаимное влияние компонент, можно быстро прийти к хаосу, которому под силу саму систему и разрушить.
Предприятие, несомненно, относится к сложным и гибким системам, поэтому хочешь – не хочешь, а его архитектуру изучать необходимо. При этом не важно, занимаемся мыпроектами, процессами или теми и другими, как обычно и происходит в реальной жизни.
Из многочисленных определений АП мне больше всего нравится это: «Архитектура предприятия – это «стратегическая информационная основа, определяющая структуру бизнеса (основной деятельности); информацию, которая необходима для ведения этого бизнеса; технологии, которые необходимы, чтобы поддерживать процессы этого бизнеса; переходные процессы, необходимые для реализации новых технологий в ответ на появление новых, изменяющихся бизнес-потребностей» [Акт Клингера-Коэна (Information Technology Management Reform Act of 1996)].
| Архитектуру предприятия имеют все компании, но не все это осознают и задумываются об этом в своей деятельности |
Акт Клингера-Коэна, более 20 лет назад принятый в США, который, в частности, провозгласил необходимость обоснованного архитектурного подхода для государственных организаций, послужил толчком грамотного развития информационных технологий не только в этой стране, но и во всем мире. Результаты этого мы со всей очевидностью могли заметить уже давно, хотя нашей страны они коснулись не так кардинально, как хотелось бы.
Как видно из этого определения, АП необходима любой компании. Потому что какая же компания может обойтись без информации и, соответственно, технологий, которые необходимы для поддержки ее процессов. Пожалуй, даже не так: АП имеют все компании, но не все это осознают и задумываются об этом в своей деятельности. Угроза подобной ситуации по мере возрастания скорости изменений и усиления конкурентной борьбы, появления клиентов нового типа и технологий, предоставляющих громадные возможности, становится все более опасной.
Даже если организация оказывается достаточно «современной» (в кавычки взяла это слово, потому что о какой современности может идти речь, если акт Клингера-Коэна принят более 20 лет назад), она чаще всего относится к АП как к застывшей окостенелой структуре. В лучшем случае будут разработаны архитектурные модели, которые, как вы понимаете, для мало-мальски значительной компании представляют собой тома, положены на полку и быстро забыты. А значит, станут достоянием истории, а не живой деятельности компании. Такая окостенелая АП ведет к разным болезням, таким как «артрит» и «артроз» организации. Кости компании становятся хрупкими и ломкими. А то еще бывает, сломает она «шейку бедра» и станет вовсе неподвижна. А там и до беды недалеко.
Увидев слово «стратегическая» в определении АП из акта Клингера-Коэна, вы, возможно, подумали, что АП важна исключительно для создания стратегии компании и реализации значительных проектов. Однако подобный вывод абсолютно не верен. Ни один процесс компании, как бизнес-процесс, так и вспомогательный или технологический, не может существовать и развиваться в отрыве от информации и управления связями между его компонентами на основе этой информации. А информация не может существовать безтехнологий, которые ее производят и поддерживают.
Я задумалась о сравнении, которое бы наглядно подтвердило эту мысль. Быстро пришло на ум сравнение с оркестром, который в отсутствие партитуры и дирижера способен произвести разве что неблагозвучную какофонию. Хотя, кто знает, не станет ли популярен в будущем такой «абстракционизм» в музыке.
Возможно, и в процессах в будущем появится мода на «какофонию». А что? При высоком уровне информационной поддержки это вполне возможно. Ведь недаром технологии управления бизнес-процессами развиваются от BPR (Business process Reengineering – реинжиниринг бизнес-процессов), через BPM (Business Process Management – управление бизнес-процессами) к Case Management (управление по событиям), когда бизнес-процессы формируются на лету в зависимости от происходящих событий, Adaptive BPM (адаптивное управление бизнес-процессами) и Agile (гибкие методики управления процессами).
Но не будем заглядывать столь далеко. Большинство процессов организации затрагивают различные компоненты и слои АП. Приведем, например, архитектурную модель FEAF (Federal Enterprise Architecture Framework), появлению которой мы обязаны уже упоминавшемуся акту Клингера-Коэна (см. рис. 1).
Рисунок 1. Слоеная модель FEAF
Хочу отметить, что большая часть того, о чем я пишу в этой статье, относится ко всем процессам, будь они бизнес-, HR-, ИТ-, деловыми или технологическими. Все процессы основываются на информации, а значит, и на нижних уровнях приведенного рисунка.
Конечно, FEAF – далеко не единст-венная модель, или, если говорить точнее, фреймворк АП. Нельзя не сказать о модели Захмана, о которой мы еще поговорим дальше, и офреймворке TOGAF (The Open Group Architecture Framework), который, кроме описания компонентов и артефактов архитектурного подхода, предлагает структуру архитектурного метода – ADM (Architecture Development Method).
Большинство процессов современной организации проходит через различные архитектурные слои. Можно даже придумать оценку цифровой зрелости организации по процентному соотношению таких процессов в общем числе процессов.
На рис. 2 приведена модель FEAF «в полный рост» с учетом динамики, а именно движения от текущей к целевой архитектуре и двигателей такого движения.
Рисунок 2. Модель FEAF в динамике
Совершенно очевидно, что изменение бизнес-процессов должно проходить в соответствии с этой моделью с учетом развития других бизнес-процессов и выполнения проектов, состоящих, в свою очередь, из выполнения процессов. Иначе архитектура просто-напросто в какой-то момент развалится, и тогда неприятностей не оберешься.
Здесь давайте вернемся к теме предыдущей статьи – классификации процессов ИТ для того, чтобы расширить и уточнить классификацию, основанную на архитектурных моделях. Возможны два варианта.
В первом процессами ИТ называются те процессы, которые затрагивают архитектуру ИТ, во втором – те, которые затрагивают только ее. Во втором случае предоставление услуг клиентам через интернет с помощью программных приложений не является ИТ-процессом, что, конечно, несколько странно.
Однако в любой компании существуют отдельные процессы или подпроцессы, которые не выходят на верхний (или верхние) бизнес-уровни, например выполнение резервной копии или закупка компонентов инфраструктуры.
Но согласитесь, что рассматривать их изолированно от остальной деятельности компании весьма опасно. Иначе, например, можно додуматься до остановки жизненно важной программной системы на профилактические работы в самый ответственный для организации момент. Именно поэтому архитектурный подход является таким важным. Ведь, занимаясь процессами ИТ независимо от остальной деятельности организации, мы рискуем вместо выгод получить одни убытки. Архитектурный подход как раз и провозглашает, что все связано, и, выигрывая в одном, как бы ни потерять в чем-то другом.
Однако тогда получается, возразите вы, что в цифровой организации все процессы являются процессами ИТ. И что же, управлять ими должно подразделение ИТ или еще того пуще внешний аутсорсер? Это же нонсенс! Нет, я далека от таких революционных мыслей. Однако учитывать особенности управления ИТ-процессами, оркестровывать управление различными процессами компании с учетом возможностей управления ИТ-процессами, необходимо. Да, и еще необходим внедренный архитектурный процесс, который позволит этоделать.
К сожалению, ни ITIL, ни COBIT, которые мы с вами кратко обсудили в предыдущей статье, не уделяют АП достойного внимания. Хотя справедливости ради надо отметить, чтопроцесс управления АП все же присутствует в COBIT в группе «Оценка, задание направления и мониторинг», но как равный в ряду других, а не определяющий и ведущий.
Итак, АП необходима для управления процессами организации. И ее основная роль состоит в том, чтобы учитывать их взаимодействие, не потерять леса за деревьями, а именно компанию за отдельными процессами, увлекшись их проектированием или оптимизацией. Процессный подход давно уже не может существовать без архитектурного, хотя это, ксожалению, осознается далеко не всеми.
| Процессный подход давно уже не может существовать без архитектурного, хотя это, к сожалению, осознается далеко не всеми |
Давайте обратимся к самим процессам. Являются ли они системой? Несомненно. А значит, для них существует архитектура. Хотя понятие «архитектура процесса» кому-топокажется непривычным и даже режущим слух, постараюсь показать, что подобный подход не только может принести существенные выгоды, но в современных условиях становится все более необходимым. Очевидно, что моделирование процесса как совокупности отдельных компонент (являющихся, кстати, в свою очередь, компонентами АП сучетом их взаимосвязей и в динамике) – это именно то, что позволит управлять ими эффективно и рационально.
Давайте для примера попробуем описать процесс ИТ с помощью модели Захмана. Сразу хочу отметить, что хотя эта, наверное, наиболее популярная архитектурная модель, была разработана Захманом с целью улучшить внедряемость корпоративных программных систем, ее применение вовсе не должно ограничиваться предприятием. Сам Захман в своей книге [John Zachman. Enterprise Architecture, 2001] описывает множество самых разнообразных примеров использования модели, и, если мне не изменяет память, только пара из них относится к предприятию. Начинает он книгу вовсе со строительства египетских пирамид. На рис. 3 приведена модель Захмана.
Рисунок 3. Модель Захмана
Как можно увидеть из рисунка, модель прекрасно подходит для процессов и процессов ИТ. В частности, владелец в данном случае представляет собой топ-менеджера, ответственного за качество, развитие и контроль процесса, функциональный менеджер отвечает за выполнение процесса в рамках требуемого качества процессов и в процессном управлении обычно называется владельцем процесса (что может, конечно, привести к определенным терминологическим проблемам), архитектор, аналитик – за то, как процесс выполняется, технический архитектор или проектировщик – за используемые технологии, в частности информационные, разработчик – за реализацию особенностей процесса, вчастности приспособление под него программных систем и других технологий, а пользователь – это тот, кто процесс выполняет.
Конечно, перспективы (строки) модели Захмана могут быть изменены, на что автор неоднократно указывал. Классические вопросы, размещенные в столбцах (аспекты модели): Кто, Что, Как, Где, Когда и Зачем, тоже могут быть изменены, сокращены или расширены. Хотя для процессов мне не приходит в голову, как их можно сократить. Может быть, у вас получится.
Хочу обратить ваше внимание, что классическая модель бизнес-процесса, приведенная в моей первой статье, прекрасно отображается моделью Захмана.
Входы: информация и материалы, и выходы: результаты, продукты и услуги, параметры качества отвечают на вопрос «Что», люди – «Кто», поиск, развитие, мотивация – «Зачем», технологии, методики, нормы, стандарты, способы оценки – на вопросы «Как», «Когда» и «Где».
Давайте теперь поговорим о том, как организовывать процессы ИТ, а именно то, что на рис. 4 обозначается синими прямоугольниками без названия. Я уже говорила о метаморфозах отношения к управлению бизнес-процессами: когда от ограниченного по срокам проектного подхода BPR перешли к непрерывной процессной деятельности по управлению бизнес-процессами – BPM, а теперь все чаще переходят к адаптивному BPM, к Agile – методологиям, которые позволяют оперативно приспосабливать процессы к изменениям внешней среды.
Рисунок 4. Состав процесса
Такой путь обусловлен объективным ускорением развития и ростом гибкости современного мира. И организациям в своих процессах приходится это учитывать. Негибкие «суставы» современной компании вполне реально могут привести ее к краху.
Процессы ИТ, стандартизация и регламентация которых связана прежде всего с ITIL и ITSM, так же как и бизнес-процессы и другие процессы организации, требуют адаптивного подхода. Но и ITIL, и ITSM относятся если не к проектному этапу в истории управления процессами, то к проектному, но никак не к адаптивному. Да и с точки зрения архитектурного подхода эти своды знаний/методологии можно легко раскритиковать.
Если посмотреть на модель Захмана, то в классическом виде в зависимости от конкретики использования она может относиться и к проектному, и к процессному подходу. Если зафиксировать все аспекты-столбцы и перспективы-строки, то получится статическая картина. На что, правда, многие указывали и указывают как на недостаток этой модели посравнению, например, с TOGAF, предлагающим непрерывное итеративное развитие АП.
А если ограничиться только частью модели Захмана, сможем ли мы достичь большей гибкости процессов? Например, не определяя, кто конкретно выполняет процесс, а задав мотивацию для его выполнения (т.е. аспект «Зачем») для тех, кто его выполнит в соответствии с требованиями качества? Это на самом деле такой популярный нынче краудфандинг, когда запрос на выполнение частей или даже целого процесса «кидается в толпу» с помощью интернета.
Или с учетом современных средств связи и роста мобильности работника для отдельных процессов, в частности ИТ, можно не определять жестко аспект «Где». Сам работник выберет наиболее успешное место выполнения. Вариант, при котором не вполне понятен аспект «Что» – что же мы собираемся сделать в результате выполнения ИТ-процессов, прекрасно иллюстрирует гибкие методологии разработки ПО (Agile).
А возможен ли такой вариант, что задав аспект «Зачем», мы не станем определять больше ничего: т.е. сотрудникам организации придется самим выяснить кто, что, как, когда и где будет выполнять. Наверное, при существующем уровне развития организаций и сотрудников это невозможно. По мере развития технологий управления знаниями это может стать реальностью.
Сегодня же по крайней мере нужны определенные более или менее жесткие правила для успешного выполнения таких слабо определенных процессов. То есть для достижения гибкости вам придется найти баланс между регламентаций, которая сокращает вероятность наступления рисков, но вместе с тем ограничивает возможности, и гибкостью, которая позволит стать максимально эффективными и быстрее реагировать на изменения, но принесет дополнительные риски. Для этого вам придется определить, какие аспекты модели процесса вы четко регламентируете, а что гибко изменяется.
Итак, процессы ИТ существуют в архитектуре предприятия и в этом качестве взаимодействуют с другими процессами и другими архитектурными компонентами. И об этом ни вкоем случае нельзя забывать. Кроме того, перспективным видится и возможность использовать архитектурные модели по отношению к самим бизнес-процессам. Ведь системы, какматрешки, вложены друг в друга. В данном случае в большую «матрешку»-предприятие вложены его процессы.
Надо только не забывать, что архитектура предприятия, как и процессов ИТ, существует всегда, видите вы ее или нет. Потому что предприятие, как и его процессы, всегда представляет собой динамическую систему. Если забыть об этом, то правильно управлять процессами не получится. В начало⇑
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Комментарии отсутствуют
Комментарии могут отставлять только зарегистрированные пользователи
|
Вакансии на сайте Jooble
|
_cover.jpg)
_cover.jpg)
_cover.jpg)
_cover.jpg)
