IT для бизнеса: Что владельцу нужно знать про описание архитектуры компании

IT для бизнеса: Что владельцу нужно знать про описание архитектуры компании

Виктор Жилин Системный аналитик, Москва

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

Кому и для чего нужна архитектура предприятия

Рискну утверждать, что с возникновением компьютеров неприятности обладателей бизнеса принципиально остались прежними. Компьютерные разработки легко стали новыми инструментами для ответа задач. За собственную продолжительную историю бизнес видел большое количество технологий и новых инструментов и удачно применял их в собственных целях: письменность, математика, двойная запись в бухгалтерском учете, разделение труда и другое.

Сталкиваясь с технологическими новинками, бизнес в лице обладателя решает две задачи:

  • Что может дать технологическая новинка бизнесу?
  • Как и в то время, когда (при каких условиях) направляться ее применять?

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

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

 

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

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

Иначе говоря АП – это писаные и неписаные правила появления, трансформации, взаимодействия и удаления составляющих элементов предприятия. Получается, что и описание АП имеется фактически у каждого предприятия. За исключением, конечно, «неписаных правил».

В чем же тогда особый интерес к применению IT для описания АП как раз на данный момент? Назову три особенности:

1) Компьютерные разработки сами по себе стали элементами АП. Их большое количество и связей между ними достаточно большое количество;

2) Компьютерные разработки связаны со многими вторыми элементами АП;

3) Изменяются компьютерные разработки весьма скоро, следовательно – скоро изменяется и АП.

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

Все, что подобные системы дают экспертам, так это данные о предмете их занятости и автоматизацию отдельных операций по обработке и подготовке данной информации.

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

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

По мере усложнения бизнеса все больше менеджеров попадает под определение пользователей АП, а их решения и неточности становятся все дороже.

Как вырабатывать описание архитектуры предприятия

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

Упрощенно, процесс описания архитектуры предприятия возможно подразделить на пять этапов:

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

Этапы №2-5 повторяются систематично.

Циклы формирования описания архитектуры предприятия

Главным в этом ходе есть этап №1, на котором создается и пересматривается неспециализированная модель описания АП. Другими словами выделяются элементы, их связи и характеристики, информацию о которых будут планировать, и формируются правила, по которым их возможно распознать, что говорится, в «настоящей жизни».

Все элементы АП обрисовать нереально, да и не требуется. В каждом цикле следует прежде всего выбирать те элементы АП, данные о которых вы вычисляете недостаточной. Громадную помощь в выборе элементов может оказать знакомство с методологиями построения и многочисленными моделями архитектуры предприятия: TOGAF, Модель Захмана, DoDAF и другими.

Советы

1) Не пробуйте сходу обрисовать сложные элементы архитектуры всецело. Выбранная модель представления АП обязана разрешать фиксировать неполноту описания. К примеру, лучше не оставлять значения обрисовываемых элементов безлюдными. В случае если какая-то из черт отсутствует – «N/A» (not applicable). В случае если значение чёрта нужно узнать – пишите «TBD» (to be defined).

Имеете возможность увеличить эту классификацию собственными категориями: «будет распознано на этапе Х», «не имеет значение на настоящий момент», «полное описание см. в совокупности Y» и т. п. В то время, когда вы осознаёте, какой как раз информацией не располагаете и тем более из-за чего – это также информация для принятия ответов.

2) Отделите описание АП от ее проектирования (разработки). Описание АП – это документирование всех осуществленных трансформаций на предприятии в соответствии с ответам, положенным в базу модели. Проектирование АП – подготовка любых трансформаций на фирмы. Эти две активности применяют различные способы.

Общее у них лишь документирование. Технически, возможно объединить в общем описании АП и описание «как имеется» (as is) и описания «как будет» (to be). Но нужно учитывать, что это различные задачи, различные компетенции, различные проекты.

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

Иерархию архитекторов, конечно, управляет обладатель бизнеса. Задача описания содержится в подготовке консолидации данных. Важный за описание АП не должен проектировать проведение каких-либо трансформаций на предприятии либо в IT.

Единственное требование к его опытным свойствам – это разработка модели АП и организация работ по ее наполнению.

4) Не спешите автоматизировать новые разработки. IT-ответ не автоматизирует всю разработку. Другими словами вы не замените технологический процесс всецело автоматическим IT-ответом. Автоматизация свидетельствует не непроизвольный процесс, а всего лишь автоматизацию отдельных операций с данными в этом ходе. Сможет ли персонал вовремя готовить эти сведенья и применять их с пользой для предприятия – это ответственность бизнеса.

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

5) Сведения об элементах АП должны предоставлять те сотрудники, каковые за эти элементы отвечают. От важных за элементы АП управление вправе ожидать того, что они компетентны по своим специализациям и готовы показать нужные знания в любую секунду. Другими словами представить отчет о состоянии их области ответственности «в письменном виде». И это никакая не дополнительная нагрузка, а прямые обязанности важных лиц. Особенно, если не накладывать никаких особых требований к форме предоставления этих сведений.

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

Из предложенного выше принципа вытекает ответственное следствие: в случае если за какой-либо элемент АП никто не отвечает, то не нужно включать его в описание АП прежде, чем будет выяснен конкретный сотрудник, важный за создание, трансформации и уничтожение (исключение) элемента.

6) Не стремитесь собрать все описание АП в одной информационной совокупности. Максимально применяйте информацию об элементах АП, каковые уже ведутся в имеющихся на предприятии совокупностях.

7) Начинайте вспоминать об описании АП тогда, в то время, когда почувствуете неуверенность в верной расстановке приоритетов собственных задач.

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

Это регулярный, более того – системный процесс. Чем внимательнее вы отнесетесь к регулярной актуализации описания АП, тем правильнее будет карта и тем больше пользы она принесет. А также применительно к определению IT-политики.

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

Редактор рубрики «IT для бизнеса» – Сергей Соловьев

Источник изображения: pixabay.com

Подготовка к собеседованию в IT компании. ответы и Вопросы. Хитрости. Трюки. Часть 2

К прочтению:

самые интересные статьи, подобранные как раз для Вас:

spacer