Файл: Разработка регламента выполнения процесса «Управление информационными ресурсами» (Теоретические основы разработки регламента выполнения процесса "Управление информационными сетями").pdf
Добавлен: 28.03.2023
Просмотров: 335
Скачиваний: 3
Существуют два общих подхода к реализации архитектуры предприятия, которые примерно соотносимы с двумя разными видами доступных инфраструктур.
Первый подход проецирует организационные артефакты и процессы на мета-структуру инфраструктуры. Этот подход хорошо работает в организациях, которые преуспели в моделировании. Организации, предпочитающие такой подход, обычно выбирают схему Захмана или эквивалентную инфраструктуру. Одна из опасностей такого подхода заключается в том, что такая инфраструктура может ограничивать творческую инициативу и вносить в процесс реализации архитектуры предприятия элемент бюрократизма. Еще одной проблемой этого типа инфраструктуры является серьезная нехватка инструкций по реализации.
Второй подход строится на убеждении, что программа архитектуры предприятия должна управляться процессами. Поскольку этот подход концентрируется, в первую очередь, на деятельностях, а не артефактах, он может быть более простым для понимания и связи с существующей рабочей средой, а также методиками и методами решения.
Хотя оба подхода имеют свои «за» и «против», можно выбрать компромиссное решение — использовать процесс, управляемый деятельностью в целом, а в качестве опорной структуры или в целях анализа применять мета-инфраструктуру.
Методологии предприятия и инфраструктуры, которые существуют сегодня, значительно отличаются по диапазону проблем, которые они решают, и подходам, которые они используют. Вот некоторые из хорошо известных инфраструктур: TOGAF, EUP, инфраструктура архитектуры федерального предприятия (Federal Enterprise Architectural Framework, FEAF), инфраструктура архитектуры предприятия Гартнера (Gartner ЕА Framework), инфраструктура архитектуры министерства обороны (Department of Defense Architecture Framework, DoDAF), методология планирования Спивака (Spewak EA Planning Methodology) и инфраструктура (схема) Захмана (Zachman Framework).
Большинство существующих инфраструктур либо расширяют другие архитектуры, либо повторяют их для конкретных задач. Например, инфраструктура EUP является расширением RUP, она имитирует его подход к описанию рабочих потоков процесса и деятельностей, тогда как FEAF и Спивак наследуют инфраструктуру Захма на 70% происходит от ранних, специализированных технических инфраструктур архитектуры предприятия, таких, как Technical Architecture Framework for Information Management (TAFIM), и создана в соответствии с рекомендациями ANSI для архитектуры предприятий.
Хотя концепции архитектуры предприятия в ходу уже более двух десятилетий, дисциплина «Архитектура предприятия» появилась недавно. Это можно объяснить ускорением изменений рабочей среды в организациях всех размеров в большинстве отраслей. Конструктивность бизнеса и, в частности, способность инфраструктуры технологий своевременно реагировать на изменения стали критически важными факторами.
В ответ на повышение внимания к принципам архитектуры предприятия в последнее время появились надежные инфраструктуры архитектуры предприятий, такие, как TOGAF.
TOGAF— это инфраструктура архитектуры предприятия, которая появилась в последние два десятилетия с целью стать стандартом разработки архитектуры предприятия. Созданная членами консорциума Open Group, TOGAF не всегда воплощает целостную концепцию архитектуры предприятия. Сначала TOGAF включала только технические аспекты архитектуры (версии с 1 по 7), однако недавно в эту инфраструктуру была добавлена предметная область архитектуры бизнеса (версия 8, Enterprise Edition), в результате TOGAF быстро переместилась на передний план современных вариантов инфраструктур архитектуры предприятий.
Главным компонентом TOGAF является метод разработки архитектуры (Architecture Development Method, метод ADM) — процесс, который используется для адаптации и реализации архитектуры предприятия, специфичной для данной организации. Помимо метода ADM, TOGAF включает коллекцию связанных средств, известных как Континуум предприятия (Enterprise Continuum). TOGAF подразумевает, что континуум предприятия действует как коллекция компоновочных блоков (шаблонов), которая предоставляет коллективам, занимающимся архитектурой предприятия, соответствующие архитектуры, модели и процессы, из которых можно собирать готовые решения, как в детском конструкторе.
Метод разработки архитектуры TOGAF (ADM) предоставляет законченный набор инструкций для реализации и выполнения архитектуры предприятия в организации. Этот процесс состоит из нескольких последовательных фаз, замкнутых в цикл.
Задача предварительной фазы (Preliminary Phase) — выявление заинтересованных в процессе реализации лиц и обсуждение с ними задач архитектуры предприятия. На этой фазе вырабатываются Руководящие принципы архитектуры (Architecture Guiding Principles), которые основываются на бизнес-принципах организации и описывают процессы и критерии для наблюдения за процессом реализации архитектуры предприятия.
Фаза А этого процесса предназначена для выражения видения архитектуры предприятия. Артефакт Видение архитектуры (Architecture Vision) использует движущие силы бизнеса, чтобы обозначить цель действий по созданию архитектуры предприятия и создать описания первого релиза для базовой и целевой среды. Если задачи бизнеса не ясны, то часть задания этой фазы — помочь бизнесу идентифицировать свои главные задачи и соответствующие процессы, которые должна поддерживать архитектура предприятия. Документ Архитектурное задание (Statement of Architectural Work), который также создается в этой фазе, очерчивает область действия и условия архитектуры предприятия и представляет собой план архитектурного задания.
Фаза В предназначена для детальной разработки архитектуры предметной области бизнеса. И базовая, и целевая архитектура, которые очерчены в документе Видение архитектуры, детализируются, чтобы получить полезные входные данные для технического анализа. Моделирование бизнес-процессов, бизнес-объектов и прецедентов — вот лишь некоторые методики, которые используются для создания архитектуры бизнеса, которая, в свою очередь, включает анализ просчетов желательного состояния.
Фаза С связана с созданием архитектуры предметных областей Приложение и Данные (Информация). Эта фаза использует базовую и целевую архитектуры, которые были запущены в фазе Л (Архитектурное представление) и при анализе просчетов (компонента архитектуры бизнеса), чтобы передать архитектурам данных и приложения информацию о текущей и проектной средах, в пределах области применения и в соответствии с планом, очерченным в документе «Архитектурное задание».
Фаза D завершает работу над детализацией архитектуры цикла метода ADM-созданием архитектуры технологии. Как и в предыдущих фазах, в качестве основы используется анализ просчетов и черновые варианты архитектур, равно как и руководящие принципы архитектуры, выработанные в подготовительной фазе. В этой фазе для создания различных точек зрения активно используется нотация моделирования UML.
Цель фазы Е — выяснить возможности, предлагаемые целевой архитектурой, и создать эскиз потенциального решения. Работа в этой фазе концентрируется вокруг применимости и практичности
альтернатив реализации. На этой фазе создаются такие артефакты, как Стратегия реализации и миграции, Высокоуровневый план реализации и Список проектов, а также обновленная Архитектура приложения, которая выполняет функции программы, которую следует использовать в проекте реализации.
В фазе расставляются приоритеты проектов реализации и выполняется детализированное планирование и анализ просчетов процесса миграции. В это задание входит оценка зависимостей между проектами и минимизация их итогового влияния на функции предприятия. В этой фазе обновляется Список проектов, детализируется План реализации, а Программа передается коллективам, занимающимся реализацией.
В фазе акцент переносится на управление изменением основой архитектуры, которая достигается поставкой реализованных решений. В этой фазе может быть создано Требование к архитектурному заданию, которое устанавливает цели для последующих циклов реализации архитектуры предприятия.
Континуум предприятия — это накопитель таких ресурсов, как модели, шаблоны решений и другие активы, которые могут использоваться как компоновочные блоки на всем процессе реализации и адаптации архитектуры предприятия. Континуум предприятия в целом аналогичен справочной библиотеке для практиков архитектуры и заинтересованных лиц.
Сегодня фаза С (архитектура информационной системы) получила дальнейшее развитие во взаимосвязи методологий TOFAG и ITIL.
TOGAF определяет последовательность строительства архитектуры предприятия на основе потребностей бизнеса, в том числе и архитектуры ИС, a ITIL определяет набор стандартных процессов, гарантирующих предоставление и поддержку ИТ-сервисов, получаемых из данной архитектуры ИС.
Интеграция систем
Современный бизнес решает триединую задачу: во-первых, необходимо устанавливать более тесные и доверительные отношения с поставщиками и заказчиками, во-вторых, повышать уровень собственной операционной эффективности и, в-третьих, повышать конкурентоспособность выпускаемой продукции. Первая составляющая обеспечивается системами поддержки отношений, получающими все большее распространение — системами SCM и CRM, вторая — еще более популярными системами ERP, а вот третья пока не имеет достаточного комплексного информационного обеспечения. На то, чтобы занять это место, претендует подход, названный new PLM (Product Lifecycle Management — Управление жизненным циклом изделия). Он заметно отличается от традиционного представления о том, что такое управление жизненным циклом изделий. Раньше под PLM (в узком смысле) чаще всего понимали то, что имело отношение к жизненному циклу материальных изделий, начиная от запуска в производство, регулирования объемов выпуска, определения времени выпуска новых или обновленных изделий, и, конечно же, сопровождение и сервис. Изменения в видении роли и места PLM произошли буквально в последние несколько лет. Теперь под этим термином понимают автоматизацию практически всех видов работ, которые составляет основу выпуска продукции — от проектирования до сбыта. Разные авторы расходятся в определениях; одни включают SCM, CRM и ERP в состав нового управления жизненным циклом изделий, другие считают эти системы взаимодополняющими.
Рассмотрим, например, следующее сравнение. В сложной автономной системе, скажем в ракете, отдельные подсистемы автоматизации образуют единое целое; такой аппарат может обходиться и без пилота. В современном автомобиле есть множество систем автоматизации, но решающую роль в управлении пока играет человек, поэтому автоматике отводится второстепенная роль; в принципе, без нее вполне можно обойтись. В автомобиле отдельные подсистемы логически связаны между собой только через посредство водителя. До сих пор примерно то же самое наблюдается и в корпоративных системах; хорошо известные системы категорий CAD, САМ, ERP, CRM, ВI и т.д., желательны, но не обязательны и, в известной мере, вторичны. Без них тоже вполне можно обойтись, никем научно не доказано их влияние на показатели работы предприятия в целом. Однако с наступлением очередной фазы электронного бизнеса ситуация меняется. Системы автоматизации становятся обязательными, приобретают первостепенную значимость и теперь должны образовывать единую систему управления. По мнению многих аналитиков, тем зонтиком, под которым они объединятся, может стать управление жизненным циклом продуктов PLM (Product Lifecycle Management).
По меркам компьютерной эры у PLM давняя история. Эти системы появились примерно два десятилетия назад, но вскоре возникла необходимость отделить автоматизацию процессов проектирования и подготовки производства (CAD/CAM) от управления информацией, сопровождающей изделия. Тогда появилось самостоятельное направление Product Data Management (PDM), т.е. управление данными об изделиях; в основном оно связано с документооборотом конструкторской и технологической документации. Те, кто хоть как-то знаком с тем, что такое выпуск и пере выпуск конструкторской документации, могут оценить значение систем управления такого рода документооборотом. Для тех, кто не знаком, может оказаться полезным слышанное от авиационных конструкторов утверждение: «Документацией на современный истребитель можно загрузить целиком большой транспортный самолет». Однако как бы ни была важна задача управления такими потоками данных, программное обеспечение PDM применялось на уровне конструкторских и технологических подразделений, не выходя на корпоративный уровень. Инструментарием PDM пользовались менеджеры не выше среднего звена.
Системы обработки транзакций оказывают помощь в выполнении операций. Обрабатывая транзакции, они насыщают информационную систему данными, осуществляя регистрацию выполнения операций. Эти данные затем используются в работе систем управленческих отчетов и систем поддержки принятия решений. СУО периодически подготавливают сведения в виде отчетов заранее установленных форм. Эти отчеты затем используются менеджерами для принятия решений. СППР также применяются менеджерами, но для принятия решений на основе собственных моделей.
Основные направления ИСУ
Существует множество направлений ИСУ: ресурсы данных, стратегическое планирование, разработка программных средств, телекоммуникационные системы, портфели приложений и др. Среди всех направлений следует выделить стратегическое планирование: это направление сохраняет высокий приоритет уже много лет. Стратегическое планирование – процесс долгосрочного планирования, осуществляемый организацией для установления цели и определения способов достижения цели. [2]
Выделяют также тактическое и оперативное планирование. Стратегическое планирование выполняет высший управленческий состав, разрабатывая генеральную стратегию, долгосрочные цели и задачи организации, а также осуществляя мониторинг реализации стратегии и ее корректировку. Тактическое планирование осуществляет средний управленческий состав, который разрабатывает кратко- и среднесрочные планы, сметы, подцели, разукрупняет стратегию по подразделениям, привлекая и размещая ресурсы, а также контролируя работу подчиненных организационных подразделений. Оперативное (контролирующее) руководство разрабатывает краткосрочные планы и программы, контролирует использование ресурсов и реализацию поставленных задач конкретными рабочими группы.