Ит архитектура практическое руководство от а до я первое издание

В книге собраны и обобщены теоретические знания и примеры реализации в таких областях ИТ, как построение архитектуры предприятия, информационной безопасности, управление ИТ-сервисами, управление проектами, качеством и рисками, бизнес-процессами. Даются системное описание ИТ, модели и подходы по формированию ИТ-стратегии, требования к системам обеспечения, выбор компонентов ИТ-инфраструктуры, расчет стоимости владения и организационные аспекты управления ИТ.

О книге «ИТ-архитектура. Практическое руководство от А до Я. Первое издание»

В книге собраны и обобщены теоретические знания и примеры реализации в таких областях ИТ, как построение архитектуры предприятия, информационной безопасности, управление ИТ-сервисами, управление проектами, качеством и рисками, бизнес-процессами. Даются системное описание ИТ, модели и подходы по формированию ИТ-стратегии, требования к системам обеспечения, выбор компонентов ИТ-инфраструктуры, расчет стоимости владения и организационные аспекты управления ИТ.

На нашем сайте можно скачать книгу «ИТ-архитектура. Практическое руководство от А до Я. Первое издание» в формате fb2, rtf, epub, pdf, txt или читать онлайн. Здесь так же можно перед прочтением обратиться к отзывам читателей, уже знакомых с книгой, и узнать их мнение. В интернет-магазине нашего партнера вы можете купить и прочитать книгу в бумажном варианте.

ИТ-архитектура. Практическое руководство от А до Я. Первое издание

В книге собраны и обобщены теоретические знания и примеры реализации в таких областях ИТ, как построение архитектуры предприятия, информационной безопасности, управление ИТ-сервисами, управление проектами, качеством и рисками, бизнес-процессами. Даются системное описание ИТ, модели и подходы по формированию ИТ-стратегии, требования к системам обеспечения, выбор компонентов ИТ-инфраструктуры, расчет стоимости владения и организационные аспекты управления ИТ.

Оглавление

© Вадим Алджанов, 2018

ISBN 978-5-4490-5650-4

Создано в интеллектуальной издательской системе Ridero

Предисловие

Об авторе

Вадим Алджанов (англ. Vadim Aldzhanov) [Microsoft MCP, MCSA Security, MCSE Security, MCTS, MCITP, MCITP SQL Database Administrator, Cisco CCNA, VMware VCP4, CompTIA A+, Network+, Security+, EC—Council CEH и ECSA, SNIA Certified Storage Professional SCSP, Wireless Technology CWTS, CWNA, CWSP, IT Management ITILv3, Apple Certified Associate — Integration Management].

В руководстве собраны и обобщены знания и опыт за более чем 17+ лет работы в ИТ. В течении 14 лет проработал в банковской сфере, большую часть времени на позиции руководителя ИТ департамента. На данный момент являюсь ИТ Архитектором в одном из крупных холдингов страны. Имею степень бакалавра по специальности «Радиотехника» и степень магистра по направлению «Компьютерные Информационные Системы (CIS)». Продолжаю образование на получение докторской степени по направлению «Менеджмент Информационных Систем (MIS)». Кроме этого имеется порядка тысячи часов обучения на специализированных курсах по направлениям системное администрирование, компьютерные сети, беспроводные сети, системы хранения, системы виртуализации, информационная безопасность, управление ИТ сервисами, управление проектами, банковское дело, пластиковые карты, стратегическое планирование, проведение аудита и прочие. Профиль в LinkedIn: https://www.linkedin.com/in/vadim-aldzhanov-623a7b44/

Цели книги

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

Книга не является обязательным руководством по выбору того или иного продукта или решения, а выражает точку зрения автора. Материал изложен в логической последовательности, дополнен теоретическими сведениями и снабжен наглядными примерами реализации. Это дает возможность использования данного руководства для методичного изучения всех аспектов деятельности ИТ, наряду с использованием его в качестве справочного пособия при работе с конкретными системами.

Сферы, охваченные книгой

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

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

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

Книга предназначена для широкого круга читателей и будут полезна:

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

Руководителям ИТ подразделений, ИТ архитекторам, менеджеров среднего звена ИТ департамента, а также менеджерам проектов книга предоставляет теоретические основы управления ИТ сервисами (ITSM) с применением рекомендаций практик ITIL, интеграцию методики Управление Проектами (PMI) в ИТ, вопросы аудита ИТ (CobiT) и Информационной Безопасности. Вся теоретическая база рассматривается на практических примерах реализации ИТ архитектуры и инфраструктуры.

ИТ специалистам помимо теоретических основ внедрения и сопровождения ИТ сервисов предоставляется возможность рассмотрения построения компонентов ИТ инфраструктуры на примере таких продуктов как Windows 2016 Server и Windows 10, комплексного решение Microsoft System Center 2016, корпоративного портала Microsoft SharePoint Server 2016 и Microsoft Project Server 2016, Exchange 2016 и Skype for Business 2015, функции Direct Access, Hyper-V и другие.

Материал изложен в логической последовательности, дополнен теоретическими сведениями и снабжен наглядными примерами реализации, что дает возможность для методичного изучения всех аспектов деятельности ИТ, наряду с использованием его в качестве справочного пособия при работе с конкретными системами.

Благодарность

Выражаю благодарность друзьям, учителям, руководителям и коллегам за помощь в написании книги, а также бесценный опыт и знания полученный от общения с такими людьми как Александр Буслаев («AIG Group»), Иршад Гулиев («SINAM»), Фазиль Маммедов («ROTABANK»), Яна Хмельницкая и Karsten Stellner («LFS Financial Systems GmbH»), Thomas Engelhardt («Microfinance Bank of Azerbaijan»), Andrew Pospielovsky («ACCESSBANK») и Alan Crompton («Baku European Games Operation Committee BEGOC 2015»).

Юридическое уведомление

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

Авторские права

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

Отказ от ответственности

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

Автор не несет никакой ответственности за прямые, косвенные, случайные или прочие убытки при использовании данного руководства. Читатель данного руководства проинформирован.

Посвящается моим родителям, любящей жене и двум прекрасным дочерям

Смотрите также

ИТ-архитектура. Практическое руководство от А до Я. Первое издание

Вадим Алджанов
ИТ-архитектура. Практическое руководство от А до Я. Первое издание

© Вадим Алджанов, 2018

ISBN 978-5-4490-5650-4

Создано в интеллектуальной издательской системе Ridero

Предисловие

Об авторе

Вадим Алджанов (англ. Vadim Aldzhanov) [Microsoft MCP, MCSA Security, MCSE Security, MCTS, MCITP, MCITP SQL Database Administrator, Cisco CCNA, VMware VCP4, CompTIA A+, Network+, Security+, EC—Council CEH и ECSA, SNIA Certified Storage Professional SCSP, Wireless Technology CWTS, CWNA, CWSP, IT Management ITILv3, Apple Certified Associate – Integration | Management].

В руководстве собраны и обобщены знания и опыт за более чем 17+ лет работы в ИТ. В течении 14 лет проработал в банковской сфере, большую часть времени на позиции руководителя ИТ департамента. На данный момент являюсь ИТ Архитектором в одном из крупных холдингов страны. Имею степень бакалавра по специальности «Радиотехника» и степень магистра по направлению «Компьютерные Информационные Системы (CIS)». Продолжаю образование на получение докторской степени по направлению «Менеджмент Информационных Систем (MIS)». Кроме этого имеется порядка тысячи часов обучения на специализированных курсах по направлениям системное администрирование, компьютерные сети, беспроводные сети, системы хранения, системы виртуализации, информационная безопасность, управление ИТ сервисами, управление проектами, банковское дело, пластиковые карты, стратегическое планирование, проведение аудита и прочие. Профиль в LinkedIn: https://www.linkedin.com/in/vadim-aldzhanov-623a7b44/

Цели книги

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

Книга не является обязательным руководством по выбору того или иного продукта или решения, а выражает точку зрения автора. Материал изложен в логической последовательности, дополнен теоретическими сведениями и снабжен наглядными примерами реализации. Это дает возможность использования данного руководства для методичного изучения всех аспектов деятельности ИТ, наряду с использованием его в качестве справочного пособия при работе с конкретными системами.

Сферы, охваченные книгой

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

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

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

Книга предназначена для широкого круга читателей и будут полезна:

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

Руководителям ИТ подразделений, ИТ архитекторам, менеджеров среднего звена ИТ департамента, а также менеджерам проектов книга предоставляет теоретические основы управления ИТ сервисами (ITSM) с применением рекомендаций практик ITIL, интеграцию методики Управление Проектами (PMI) в ИТ, вопросы аудита ИТ (CobiT) и Информационной Безопасности. Вся теоретическая база рассматривается на практических примерах реализации ИТ архитектуры и инфраструктуры.

ИТ специалистам помимо теоретических основ внедрения и сопровождения ИТ сервисов предоставляется возможность рассмотрения построения компонентов ИТ инфраструктуры на примере таких продуктов как Windows 2016 Server и Windows 10, комплексного решение Microsoft System Center 2016, корпоративного портала Microsoft SharePoint Server 2016 и Microsoft Project Server 2016, Exchange 2016 и Skype for Business 2015, функции Direct Access, Hyper-V и другие.

Материал изложен в логической последовательности, дополнен теоретическими сведениями и снабжен наглядными примерами реализации, что дает возможность для методичного изучения всех аспектов деятельности ИТ, наряду с использованием его в качестве справочного пособия при работе с конкретными системами.

Благодарность

Выражаю благодарность друзьям, учителям, руководителям и коллегам за помощь в написании книги, а также бесценный опыт и знания полученный от общения с такими людьми как Александр Буслаев («AIG Group»), Иршад Гулиев («SINAM»), Фазиль Маммедов («ROTABANK»), Яна Хмельницкая и Karsten Stellner («LFS Financial Systems GmbH»), Thomas Engelhardt («Microfinance Bank of Azerbaijan»), Andrew Pospielovsky («ACCESSBANK») и Alan Crompton («Baku European Games Operation Committee BEGOC 2015»).

Юридическое уведомление

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

Авторские права

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

Отказ от ответственности

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

Автор не несет никакой ответственности за прямые, косвенные, случайные или прочие убытки при использовании данного руководства. Читатель данного руководства проинформирован.

Посвящается моим родителям, любящей жене и двум прекрасным дочерям

Часть I: Теоретические Основы

Книга разбита на две части. Содержание первой части книги включает в себя рассмотрение теоретических основ по построению ИТ компании. В частности, рассмотрены:

Глава 1: Концепции построения Архитектуры Предприятия – В данной главе рассматриваются вопросы построения Архитектуры Предприятия, построения ИТ стратегии и т п.

Глава 2: Концепция Управления Проектами – в главе рассматриваются основы Управления Проектами, применяемые методологии, принятые методы и т п.

Глава 3: Концепция Управления Рисками – в главе рассматриваются методики и методы оценки рисков, классификация рисков и типы реагирования на риски.

Глава 4: Концепция Управления Качеством – в главе рассмотрены базовые принципы и методы управления проектами при использовании методов, основанных на принципах управления качеством и бережливого производства.

Глава 5: Концепция Управление Бизнес Процессами и Модели Деловой Активности различных сфер бизнеса, Рассмотрены основы построения бизнес процессов, виду организации бизнеса и связь с информационными системами.

Глава 6: Концепция Интеграции Данных и централизация ИТ – В данной главе рассмотрены вопросы по интеграции данных между различными информационными системами, различные архитектурные решения, проблемы и возможности. Рассмотрены уровни централизации Автоматизированных Систем Управления.

Глава 7: Концепция выбора ИТ решений – Рассмотрены проблемы выбора ИТ решений, а также предложены механизмы по выбору и обоснованию того или иного решения.

Глава 8: Концепция Информационной Безопасности – Рассмотрены вопросы информационной безопасности, порядок организации взаимодействия информационной безопасности и ИТ.

Глава 9: Концепция Управления ИТ сервисами – Рассмотрены процессы построения управления ИТ сервисами с применением практики ITIL.

Глава 10: Концепция Контроля и аудита ИТ – рассмотрены общие вопросы по контролю ИТ и проведению аудита

Глава 11: Концепция Определение стоимости и модели финансирования ИТ – Рассмотрены модели финансирования, принципы оценки ИТ проектов, методы и практики расчета стоимости ИТ сервисов и т п.

Концепция Архитектуры Предприятия

Общие Положения

В данной главе описывается общая информация по Архитектуре Предприятия (Enterprise Architecture). Обобщенное определение можно представить, как:

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

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

•TOGAF – Enterprise Architecture

•ISO/IEC 20000 – Quality in IT Service Management

•ISO/IEC 27000 – Best Practice IT Security Standards

•CobiT v5 – Audit and Control Framework

•ITIL v3 – Best practices in IT Service Management

•MOF – Microsoft Operations Framework

•PMI – Project Management Institute

Архитектура призвана ответить на такие вызовы и проблемы организации как:

•Недовольство бизнеса ИТ‐службой. Причины могут быть объективные или субъективные.

•Невозможность оценить эффективность использования информационных технологий в бизнесе.

•Отсутствие порядка в «зоопарке» ИТ решений и систем, внедренных в организации.

•Сложность принятия решений, связанных с информационными технологиями

•Сложность согласование ИТ‐бюджета и запуск ИТ‐проектов.

•Рост ценности «Информации» и связанности бизнеса и ИТ.

•Отсутствие прозрачных и понятных связей бизнеса и ИТ?

•Можно ли решить актуальные задачи бизнеса с использованием ИТ?

•Как заставить ИТ давать компании большую ценность?

•Как нужно менять ИТ при изменениях в бизнесе?

•ИТ системы сложны, не управляемы и дороги в обслуживании

•ИТ системы сдерживают организацию от адекватного реагирования на изменения в бизнесе

•Критичная для бизнеса информация не своевременна и не адекватна

•Отсутствует культура общения бизнеса и ИТ

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

Основные аспекты Архитектуры Предприятия

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

Определение Структуры Предприятия

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

Структура организации – фиксированное упорядоченное множество объектов и связей между ними.

По характеру специализации и видам деятельности различают:

Вертикальное разделение – по уровню подчинения

Горизонтальное разделение – по функциям и специфики деятельности

Соответственно в структуре управления различают линейные связи по типу «начальник – подчинённый» и функциональные «профессиональная интеграция на основе специфики деятельности». Как результат, тип структуры организации можно представить, как следующие основные типы и их разновидности:

Плоская – наиболее простая структура. Подходит для рабочих или проектных групп, или небольшой организации.

Иерархическая (бюрократическая) – формирование структуры исходя из структуры организации, разделение труда на функции и ответственности работников.

Линейная – управление по прямой (руководитель – подчинённый), общение между подразделениями только через руководителей подразделений

Функциональная – взаимодействие идет по функциональному признаку

Линейно-функциональная – взаимодействие совмещается по линейному и функциональному типу (наиболее используемая модель)

Линейно-штабная – отдельные функциональные группы (штабы), самостоятельно ведущие работу с подразделениями или организациями. Как пример группа компаний в составе холдинга.

Дивизионная – характеризуется центральной координацией с децентрализованным управлением. Ключевые фигуры в данном случае не руководители функциональных подразделений, а менеджеры отдельных объединений (менеджеры филиалов, заводов и т п)

Органические (адаптивные) – формирование структуры исходит из необходимости приспособления к изменениям. Отношения формируются, исходя не из структуры, а характера поставленных задач.

Проектные – организуется при ведении проектов

Матричные (программно-целевые) – принцип двойного подчинения, непосредственное подчинения руководителю, и проектному менеджеру

Бригадные (кросс-функциональные) – работа обособленными группами, с самостоятельным управлением и принятием решений (противоположность иерархическому типу)

Существование той или иной организационной структуры может зависеть от ряда факторов:

•Специфика и степень разнообразия деятельности

•Географическое размещение

•Уровень централизации в организации

•Стратегия организации

•Количества и спектра предоставляемых услуг

Определение роли ИТ в составе организации

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

Для понимания роли ИТ в конкретной организации нужно ответить на следующие вопросы:

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

Вашу организацию можно отнести к крупному или среднему бизнесу. На мой взгляд, до тех пор, пока все технологии компании со всеми подробностями помещаются в одной голове, а ИТ директор напрямую общается с руководством организации об архитектуре предприятия думать рано. Для малого бизнеса архитектура предприятия вообще, как телеге пятое колесо.

Компания активно развивает ИТ. В компании идет несколько ИТ проектов в год, или хотя бы один проект по внедрению ERP, CRM или прочего сложного решения. Формирование Архитектуры Предприятия поможет с принятием решений и убережет от большинства переделок, ошибок, не состыковок, задержек и прочих проблем. У кого-то, и желательно не одного, должна быть общая картинка будущего и понимание процесса развития. Иначе кусочки мозаики, созданные в разных проектах, не сойдутся.

У компании периодически происходят кризисы в ИТ, которые имеют существенное влияние на бизнес. В информационных системах происходят сбои, которые негативно влияют на бизнес, вплоть до его остановки. Сбои вызваны проблемами в интеграции, просчетами в инфраструктурных решениях, временными решениями и просто бардаком. Не все проекты, в том числе и ИТ, заканчиваются успешно, уложившись в сроки, бюджет и заявленные требования. Если руководство вашей компании устало от провалов, задержек, превышения бюджетов ИТ проектов, то стоит задуматься.

Компании важна скорость, качество и эффективность развития ИТ. Одна из сторон (Бизнес или ИТ) развивается значительно быстрее чем другая. В случае, если бизнес развивается быстрее чем ИТ, то ИТ становится тормозом в развитии компании. И наоборот, если ИТ развивается быстрее чем необходимо бизнесу, то владельцы бизнеса несут убытки как финансовые (хорошее ИТ стоит денег), так и упущенная прибыль (бизнес не использует все потенциальные возможности ИТ). Необходимо организовать работу обоих сторон «на одной волне» для гармоничного развития всех элементов компании.

Выстраивание взаимоотношения между бизнесом и ИТ

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

Наладить сотрудничество между бизнесом и ИТ.

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

Получить максимальную ценность от ИТ.

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

ЦЕННОСТЬ = ВЫГОДА – ЗВТРАТЫ

С точки зрения бизнеса: Получить максимальную ценность от ИТ. Ценность информационных технологий – это разница между выгодами использования информационных технологий и затратами на них).

С точки зрения ИТ: Соблюдение ИТ ценностей и требований (технологичность, безопасность и управляемость ИТ).

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

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

Управлять изменениями.

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

Навести порядок и управлять развитием ИТ.

Современные реалии ведения бизнеса и развития технологий приводит к тому, что бизнес требует внедрение все новых и новых технологические решения. Различные методы и модели их внедрения (самостоятельная разработка, покупка «коробочного» решения, внедрение и сопровождение со стороны третьей стороны и т п) приводит к тому, что в ИТ инфраструктуре появляется большое количество различного аппаратного и программного обеспечения, частично дублирующего друг друга, устаревших решений, и т п. Кроме этого, постоянная зависимость от специалистов, обладающих «уникальными» знаниями и опытом. Задача ИТ директора – организация управления ИТ, непрерывное обучение сотрудников новым технологиям, выбор перспективных направлений, которые могут принести выгоду бизнесу.

Вы здесь

Концепция управления качеством

Общие Положения

Данный раздел содержит основные принципы управления качеством, которые должны быть приняты во внимание при проектировании архитектуры. При разработке концепции учитывались международные стандарты ISO9000, ISO8402, BS7925—1.

Современная концепция управления качеством имеет в своей основе следующие основополагающие принципы:

•Качество – это неотъемлемый элемент любого проекта

•Качество – это то, что определяет потребитель, а не изготовитель

•Ответственность за качество должна носить адресный характер

•Повышение качества в современном мире зачастую зависит от уровня технологий

•Повышение качества возможно только усилиями всех сотрудников организации

•Контроль процессов более эффективен, чем контроль результатов

•Политика управления качеством должен быть общей политикой организации

Основные аспекты качества

Качество обусловлено соответствием требований и ожиданий бизнеса, полноты и точности анализа

Качество достигается за счет тщательной разработки проекта и его сопровождения

Соответствие запланированных характеристик проекта или продукта его фактическим характеристикам

Качеством материально-технического обеспечения на всем жизненном цикле продукта или сервиса

Основные процессы управления качеством

Quality Assurance (QA) – обеспечение качества. Это совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации ИТ сервиса, предпринимаемых на разных стадиях жизненного цикла, для обеспечения требуемого уровня качества.

Quality Control (QC) – контроль качества. Это совокупность действий, проводимых над продуктом или сервисом в процессе разработки, для получения информации о его актуальном состоянии в разрезах:

•готовность продукта к выпуску,

•соответствие зафиксированным требованиям

•соответствие заявленному уровню качества продукта.

Testing – тестирование. Одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis). Условно можно разделить на две категории:

•Верификация (Verification) – процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале проекта.

•Валидация (Validation) – это определение соответствия, разрабатываемого ПО ожиданиям и бизнес требованиям.

Quality Improvement (QI) – повышение качества. Это совокупность мероприятий, для обеспечения улучшение или повышение уровня качества.

Участники процесса и их роли

Основные участники процесса контроля, управления и анализа качества являются рабочие и экспертные группы, в состав которых могут входить:

•Руководство бизнеса

•Департамент Внутреннего Аудита как владелец процесса управления качеством,

•Бизнес подразделения (в случае проектов, связанных с ИТ) портфелей, как заказчики ИТ сервисов

•ИТ департамент в составе экспертной группы ИТ специалистов, управление качеством ИТ сервисов

•Возможно участие сторонних консультантов

Концепция Управления Проектами и Контроля Качества «Шесть сигм» (six sigma)

Концепция «шесть сигм», которую иногда называют методологией, была разработана компанией Motorola для исключения лишних потерь, улучшения процессов и повышения прибыли. Основная цель SIX SIGMA – улучшение процессов и качества продукции за счет снижения дефектов или ошибок. Рейтинг/градация «6 сигма» означает, что 99,99966% от того, что производится – является бездефектным. Проверяя процессы производства в целом, Вы можете найти возможные улучшения и доработки даже перед появлением дефектов. Методология, построенная на основе анализа данных, включает три ключевых компонента:

•DMAIC (define, measure, analyze, improve and control) – определение, измерение, анализ, улучшение и контроль;

•DMADV (define, measure, analyze, design and verify) – определение, измерение, анализ, проектирование и проверка;

•DFSS (Design for Six Sigma) – проектирование для шести сигм. DFSS может включать как предыдущие, так и другие варианты: например, IDOV (identify, design, optimize and verify) – идентификация, проектирование, оптимизация и проверка.

Данная методика ориентирована на получение высокого уровня качества, единичных ошибки на миллион операций (стандартные метод «4 Sigma» порядка шести тысяч ошибок на миллион операций).

Основные базовые принципы:

•Интерес к клиенту

•Управление на основе фактов

•Ориентированность на процесс, управление и улучшение

•Проективное управление

•Прозрачное взаимодействие (внутри организации без административных и иерархических барьеров)

•Стремление к совершенству и принятие неудач

Основы метода»6 Sigma «можно сформулировать цепочкой (замкнутым циклом) действий DMAIC:

Определение (Define):

•Точное определение проблем и целей

•Выявление требований клиентов

Измерение (Measure):

•Сбор исходных данных

•Проведение измерений

•Статистическая оценка

Анализ (Analyze):

•Анализ данных и процесса

•Определение взаимосвязей

•Идентификация и верификация причин

Улучшение (Improve):

•Систематический поиск и выбор оптимального решения

•Реализация оптимального решения

Контроль (Control):

•Последовательное и долговременное определение уровня качества

•Управление процессом

Основные отличительные черты метода:

•Наличие сильного руководителя

•Результаты должны быть измеряемы

•Градация сотрудников по уровню компетенции

•Принятие решений только на основе проверенной информации, а не домыслов и предположений

В концепции 6 сигма уделяется отдельное внимание устранению возникающий проблем.

Конечная цель проекта – удовлетворение заказчика качеством продукта, которого можно добиться при помощи непрерывного процесса улучшения всех аспектов проекта, основанном на тщательном анализе показателей. При рассмотрении методологии с точки зрения управления проектами цепочка была предложена цепочка процессов из 5 шагов, известных как DMEDI:

Определение (Define): Первый этап очень похож на ранние этапы других систем проектного управления. На нём определяется содержание проекта, собирается информация о предпосылках проекта, ставятся цели.

Измерение (Measure): 6 сигм ориентирована на сбор и анализ количественных данных о проекте. На данном этапе происходят определяется, какие показатели будут определять успех проекта и какие данные нужно собирать и анализировать.

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

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

Контроль (Control): Ключевой этап в методологии 6 сигм. Его основная задача – долгосрочное улучшение процессов реализации проектов. Данный этап требует тщательного документирования извлечённых уроков, анализа собранных данных и применения полученных знаний как в проектах, так во всей компании в целом.

Методология «Шесть Сигм» более структурированная версия Lean нежели Kanban, в которую добавлено больше планирования для экономии ресурсов, повышения качества, а также снижения количества брака и проблем. «Шесть Сигм» очень похожа на Kanban, только с установленными этапами реализации задач – планированием, определением целей и тестированием качества. Вероятнее всего, встреч команды при применении «Шесть Сигм» будет значительно больше, чем при Kanban, но зато процесс реализации проектов более структурирован и команде сложнее сбиться с пути. Как и Kanban, «Шесть Сигм» можно относительно легко адаптировать к нуждам конкретной компании или команды. Жёстким требованием является лишь тщательное измерение и контроль показателей проекта на этапах реализации – без этого невозможно постоянное долгосрочное улучшение процессов реализации проекта. Описывается стандартами:

•«ISO 13053—1:2011 Количественные методы в процессах улучшения. Шесть сигм. Методология DMAIC»

•«ISO 13053—2:2011 Количественные методы в процессах улучшения. Шесть сигм. Инструменты и техники».

В последнее время, метод «6 Sigma» тесно переплетается с философией «LEAN» – бережливое производство.

Сильные стороны Концепция «Шесть Сигм» предоставляет чёткую схему для реализации проектов и постоянного улучшения процессов. Определяя цели, затем тщательно анализируя их и пересматривая вы получаете количественные данные для более глубокого понимания проекта и принятия более качественных решений. И хотя сбор, анализ данных и извлечение уроков могут занять определённое время, это позволит улучшить и оптимизировать процессы реализации проекта и сэкономить таким образом ресурсы в будущем. 6 сигм подходит для трудных проектов, в которых много новых и сложных операций. Данный подход позволяет реализовывать элементы проекта, учиться на ошибках и повышать качество в будущем.

Слабые стороны Проблема методологии «Шесть Сигм» в том, что, хотя основной декларируемой целью является снижение затрат и повышение эффективности, но удовлетворение заказчика часто вырывается на первый план. Учитывая некоторые различия в целях на разных этапах проекта, часто у команд возникает путаница в приоритетах, и избежать этого не просто. Кроме того, основной лейтмотив «Шесть Сигм»: «Всё всегда можно сделать ещё лучше». Это может демотивировать сотрудников, не чувствующих удовлетворения от проделанной работы. Кроме того, если проект единичный и компания не планирует в будущем реализовывать подобные проекты, все затраты на анализ и извлечение уроков могут оказаться напрасными.

Управление Проектами и Концепция Бережливого Производства (LEAN)

LEAN (Бережливого производства/разработки) – концепция, инициатив по непрерывному улучшению процессов. Кроме выше упомянутого можно принять во внимание теорию ограничений «барабан – буфер – веревка». Суть методики в поиске и определении ограничений в процессе производства. При воздействии на ключевые элементы системы, можно добиться больших результатов, чем при одновременном воздействии на все компоненты. Суть элементов:

•Барабан – производство работает по некоторому «ритму»

•Буфер – перед ограничением должен иметься буфер (ресурсов) для предотвращения простоя производства

•Веревка – материалы должны подаваться только когда они достигли своего разрешенного минимума

Задачи LEAN или бережливое производство, заключается в создании ценностей высокого уровня и обеспечении высочайшего качества работы с меньшими трудовыми ресурсами, средствами и временем. Lean сокращает потери, устраняя узкие места, фокусируясь на ценностях потребителя и постоянно улучшая процесс производства. Использование Lean помогает сократить расходы, оперативно выполнять работу в поставленные сроки, достигать существенных результатов в составе малочисленных команд, привлекая к выполнению задачи минимальное количество человеческих ресурсов.

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

Agile говорит нам, что необходимо разбивать на небольшие управляемые пакеты работ, но ничего не говорит о том, как управлять разработкой этого пакета. Scrum предлагает нам свои процессы и процедуры. Lean же, в свою очередь, добавляет к принципам AGILE схему потока операций (workflow) для того, чтобы каждая из итераций выполнялась одинаково качественно. В Lean, так же, как и в Scrum, работа разбивается на небольшие пакеты поставки, которые реализуются отдельно и независимо. Но в Lean для разработки каждого пакета поставки существует поток операций с этапами, подобными тем, которые были созданы для проекта Аполлон. Как и в классическом проектном менеджменте, это могут быть этапы планирования, разработки, производства, тестирования и поставки – или любые другие необходимые для качественной реализации проектов этапы.

Этапы Lean и их гибкость позволяют быть уверенными в том, что каждая часть проекта реализуется так, как требуется. В Lean не прописаны чёткие границы этапов, как в Scrum прописаны ограничения Спринтов. Кроме того, в отличие от классического проектного менеджмента, Lean позволяет параллельно выполнять несколько задач на разных этапах, что повышает гибкость и увеличивает скорость исполнения проектов. Как и Agile, Lean это скорее концепция, образ мышления, нежели нечто высеченное в камне. Используя идеи Lean Вы можете самостоятельно создать систему, удовлетворяющую вашим требованиям в управлении проектами.

Сильные стороны – Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.

Слабые стороны – Не каждая часть проекта требует одинаково детальной и дотошной проработки и внимания. Но Lean предполагает именно такой подход к каждой задаче и этапу. Это основной минус применения Lean для крупных и неоднородных проектов. А ещё, в отличие от Scrum, Lean не предлагает чёткого рабочего процесса для реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Эта проблема может быть решена при помощи эффективного руководства и чётких коммуникаций – главное помнить об этом.

Основные методы контроля качества

Метод «7 Основных (японских) инструментов контроля качества»

Метод представляет из себя набор инструментов для сбора и анализа информации, Методы предоставляют возможность для последующего анализа дефектов и контроля качества. Состав инструментов включает в себя:

•Лист Сбора Данных

•Гистограммы

•Потоковые диаграммы

•Схема Исикавы «Рыбья Кость» (причинно-следственная связь)

•Диаграмма корреляции (рассеивания)

•Контрольная карта Шухарта

Рассмотрим набор инструментов и методов более подробно.

Лист сбора данных

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

Гистограмма

Изменение какой-либо величины с учетом частоты ее распределения. Обычно графически представляется в графическом виде как столбцы с данными.

Потоковая диаграмма

Графическое отображение последовательности операций в рамках отдельного процесса, с указанием альтернативных путей развития событий в случае выполнения определённых условий.

Схема Исикава «Рыбья кость» (причинно-следственная диаграмма)

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

Все возможные причины классифицируются по пяти «5М» возможным категориям:

•Man – причины, связанные с человеческим фактором

•Machines – причины, связанные с машинами, техникой

•Materials – причины, связанные с материалами

•Methods – причины, связанные с методами, технологией и процессами

•Measurements – причины, связанные с методами измерений

К оси сходятся ветви «причины», каждая из которых состоит из «веточек», приводящих к возникновению причины. Все это ведет к результату «голове рыбы» – следствию.

Диаграмма Парето (Pareto Chart)

Принцип Парето гласит: 20% процентов причин порождает 80% процентов проблем. Диаграмма помогает визуально выявить основные причины, оказывающие наибольшее влияние на возникновение той или иной проблемы.

Данная диаграмма позволяет с помощью минимальных направленных действий эффективно решать проблемы. Следующие 30% процентов причин порождают порядка 15% процентов проблем. И наконец оставшиеся 50% процентов причин создают не более 5% проблем.

Обратный тезис «для устранения оставшихся 20% процентов проблем потребуется порядка 80% процентов ресурсов» также верен.

Диаграмма корреляции (рассеивания)

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

Контрольная карта Шухарта

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

Горизонтальные линии отображают допустимые границы, контрольные карты могут различаться по двум основным признакам:

качественные показатели (годен не годен, и т п). Существует четыре типа карты для данного признака:

•U – карта (число дефектов на единицу продукции в переменном объеме выборки)

•С – карта (число дефектов в постоянном объеме выборки)

•Р – карта (доля дефектных изделий в переменном объеме выборки)

•NP – карта (число дефектных изделий в постоянном объеме выборки)

и количественные показатели

Кроме этого существую другие методы

Анализ характера и последствий отказов (Failure Mode and Effect Analysis, FMEA)

Анализ характера и последствий отказов (Failure Mode and Effect Analysis, FMEA) – анализ причин и последствий отказов. Метод анализа, применяемый в менеджменте качества для определения потенциальных дефектов (несоответствий) и причин их возникновения в изделии, процессе или услуге. Он применяется для выявления проблем до того, как они проявятся и окажут воздействие на потребителя.

Существует три основных вида FMEA, определяемых по объекту анализа:

•FMEA – анализ технической системы. Направлен на выявление проблем в основных функциях системы;

•FMEA – анализ конструкции. Направлен на выявление проблем в компонентах и подсистемах изделия;

•FMEA – анализ процесса. Направлен на выявление проблем в процессах производства, сборки, монтажа и обслуживания изделия.

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

FMEA – анализа связано с улучшением конструкции изделия (характеристик услуги) и процессов по его изготовлению и эксплуатации (предоставлению услуги). Анализ может применяться как по отношению к вновь создаваемым изделиям (услугам) и процессам, так и по отношению к уже существующим.

FMEA – анализ выполняется, когда разрабатывается новое изделие, процесс, услуга, или проводится их модернизация; когда находится новое применение для существующего изделия, процесса или услуги; когда разрабатывается план контроля нового или измененного процесса.

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

FMEA – анализ выполняется в следующем порядке:

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

•Определяются варианты применения анализа. FMEA может являться частью комплексного анализа, при котором применяются различные методы. В этом случае FMEA должен согласовываться с анализом системы в целом. Основные варианты могут включать:

анализ сверху-вниз. В этом случае объект анализа разбивается на части и FMEA начинают проводить с наиболее крупных частей.

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

анализ компонентов. FMEA выполняют для физических элементов системы.

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

•Определяются границы, в пределах которых необходимо рассматривать несоответствия. Границами могут являться – период времени, тип потребителя, география применения, определенные действия и т. п., например, несоответствия, выявляемые только при окончательном контроле и тестировании.

•Разрабатывается подходящая таблица для регистрации информации. Она может изменяться в зависимости от учитываемых факторов. Наиболее часто применяется таблица следующего вида.

•Определяются элементы, в которых возможно возникновение несоответствий (отказы). Элементы могут включать в себя различные компоненты, сборки, комбинации составных частей и пр. Если список элементов становится слишком большим и неуправляемым необходимо сократить границы FMEA.

В том случае если потенциальные отказы связаны с критическими характеристиками, дополнительно, при проведении FMEA, необходимо проводить анализ критичности отказов. Критические характеристики – это нормативы или показатели, которые отражают безопасность или соответствие нормативным требованиям и нуждаются в особом контроле.

•Для каждого элемента, выделенного на шаге 5, составляется список наиболее значимых видов отказов. Эту операцию можно упростить, если применять стандартный список отказов для рассматриваемых элементов. Если проводится анализ критичности отказов, то необходимо определить вероятность появления отказа для каждого из элементов. Когда определены все возможные виды отказов для элемента, тогда суммарная вероятность их возникновения должна составлять 100%.

•Для каждого вида отказа, выявленного на шаге 6, определяются все возможные последствия, которые могут проявиться. Эту операцию можно упростить, если применять стандартный список последствий. Если проводится анализ критичности отказов, то необходимо определить вероятность возникновения каждого последствия. Когда определены все возможные последствия, вероятность их возникновения суммарно должна составлять 100% для каждого элемента.

•Определяется рейтинг тяжести последствий для потребителя (S) – Severity. Рейтинг тяжести последствий обычно определяется по шкале от 1 до 10, где 1 означает незначительные последствия, а 10 катастрофические последствия. Если вид отказа имеет более одного последствия, то в FMEA таблицу вносится только наиболее тяжелое последствие для этого вида отказа.

•Для каждого вида отказа определяются все потенциальные причины. Для этого может применяться причинно-следственная диаграмма Исикавы. Все потенциальные причины для каждого вида отказов заносятся в таблицу FMEA.

•Для каждой причины определяется рейтинг вероятности ее возникновения (O) – Occurrence. Вероятность возникновения обычно оценивается по шкале от 1 до 10, где 1 означает крайне маловероятное событие, а 10 означает неизбежное событие. Значение рейтинга заносится в таблицу FMEA.

•Для каждой причины определяются существующие методы контроля, которые применяются в данный момент, чтобы отказы не оказали влияния на потребителя. Эти методы должны предотвращать возникновение причин, снижать вероятность того, что произойдет отказ или обнаруживать отказ после проявления причины, но до того, как причина оказала влияние на потребителя.

•Для каждого метода контроля определяется рейтинг обнаружения (D) – Detection. Рейтинг обнаружения обычно оценивается по шкале от 1 до 10, где 1 означает, что метод контроля абсолютно точно обнаружит проблему, а 10 – не сможет обнаружить проблему (или контроля вообще не существует). Рейтинг обнаружения заносится в таблицу FMEA.

•Рассчитывается приоритетное число риска (риск потребителя – RPN) которое равно произведению S * O * D. Это число позволяет ранжировать потенциальные отказы по значимости.

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

•После выполнения рекомендованных действий значения рейтингов S,O,D оцениваются заново, а приоритетное число риска RPN пересчитывается.

Анализ первопричины (Root Cause Analysis) и Анализ Дерева Отказов (Failure Tree Analysis FTA)

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

Анализ дерева отказов – это методика идентификации и анализа факторов, которые могут способствовать наступлению некоторого нежелательного события (называемого вершинным («top event»)). Факторы-причины определяются дедуктивным способом, логически выстраиваются и представляются графически в виде диаграммы-дерева, которая изображает связь факторов-причин с основным событием. Достоинства метода:

Графическое изображение того, как может возникнуть вершинное событие, с отображением взаимодействующих путей, когда два или более событий могут возникнуть одновременно;

Список минимальных разрезов (отдельных путей к сбою) с вероятностями их возникновения (при наличии данных);

Вероятность вершинного события

Понравилась статья? Поделить с друзьями:
  • Ринофломуцин инструкция по применению для детей отзывы
  • Korax сироп от кашля инструкция на русском турция
  • Haylou gt1 plus инструкция на русском
  • Мазь стоп моллюск инструкция по применению
  • Стиральная машина узкая whirlpool bl sg7108v mb инструкция