Развитие программных продуктов и методологий управления бизнесом привело к появлению новых идей интегрированного управления, которые базировались на концепции «целевой интеграции» процессов, направленных на наиболее полное удовлетворение потребностей или конечного пользователя продукции. Более простым выражением этой же идеи является термин «процессный подход в управлении».
Ни одна современная организация не работает без системы или систем какого-либо рода, при помощи которых достигаются цели функционирования этой организации. Информационная система — это комбинация ручных и компьютерных процессов, которые решают поставленные задачи, четко и логично взаимодействуя между собой. В условиях современной конкурентной экономики, использование развитых информационных систем помогает организациям занимать лидирующие позиции в их бизнесе.
Существует множество подходов к решению задач, связанных с проектированием и построением информационных систем. Большинство подходов опирается на инструментальные средства, позволяющие автоматизировать создание системы. Поэтому деятельность такого рода получила название CASE (Computer Aided Software Engineering). Задача по созданию информационной системы делится на несколько подзадач. Это разделение зависит от применяемого подхода, но в любом из них всегда присутствуют два действия: сбор информации и моделирование бизнеса; построение архитектуры будущей системы, что является важным шагом на пути к ее созданию.
При моделировании бизнеса рассматриваются три аспекта:
• объекты, с которыми оперирует бизнес;
• процессы, которые он выполняет;
• события, управляющие изменениями процессов и объектов. Соответственно, можно определить три типа моделирования:
• информационное,
• функциональное,
• событийное.
Внедрение информационной системы всегда приводит к реорганизации бизнеса. В значительной степени предмет деятельности остается без изменений, в то время как меняются способы и участники этой деятельности. Модели, используемые для определения потребностей бизнеса, должны позволять делать обоснованные изменения в организационной структуре. Эти модели должны как можно меньше зависеть от известных информационных технологий. Система должна быть открыта в сторону введения новых процедур, например, производства, продаж, управления или учета.
Многие предприятия выбирают себе ИС, а значит, определяют свои требования к информационной поддержке со стороны системы. Как правильно сформулировать эти требования и с первого раза построить оптимальную систему?
Оставим в стороне технические особенности различных ИС, как то: требования к серверам, операционным системам и т.д. Нужно четко понимать, что технические требования подчинены требованиям системы управления, а не наоборот. На первом месте должны стоять требования по функциональности системы, ее соответствию целям предприятия. Она должна стать частью системы управления и поддерживать деятельность руководства и персонала, предоставляя нужную информацию для принятия решений.
Кроме того, ИС должна охватывать все функциональные области, существующие на предприятии: закупка, хранение, перемещение, производство, продажи и т.д. И если предлагаемая система решает все задачи в закупках, но не решает в производстве или продажах, то это тоже неполноценная ИС.
Выбор ИС происходит на четырех уровнях принятия решений:
1. Стратегический, на котором определяются: цель проведения автоматизации; области автоматизации; назначение ИС.
2. Функциональный, на котором определяются: требуемые функции ИС; функциональные возможности существующих предложений; соответствие предложений требованиям.
3. Операционный, на котором выбираются: операционная система; СУБД, язык доработки и т.д.
4. Аппаратный, на котором выбираются: оргтехника, отвечающая требованиям операционного и функционального уровней; сетевые решения.
Ниже представлены требования к Информационной Системе в целом и к ее основным составляющим:
1. Достаточность или функциональная полнота системы. Система должна обеспечивать выполнение международных стандартов управленческого учета — MRP II, ERP, CSRP. Необходимым условием является наличие вычислительных ресурсов с заложенной избыточностью, определяемой перспективными требованиями Единой Информационной системы (ЕИС), и автоматизация в рамках системы решения задач:
• планирования, бюджетирования, прогнозирования;
• оперативного (управленческого) учета;
• бухгалтерского учета;
• статистического учета;
• финансово-экономического анализа.
2. Достоверность. Составляющими достоверности информации являются: Релевантность информации. Основное назначение информационных сообщений (справок), выдаваемых информационной системой для анализа руководством, — снятие неопределенности. Это должно, в свою очередь, предопределять его поведение при принятии управленческих решений. Очевидно, что содержание информации должно соответствовать потребностям решаемой проблемы.
3. Толерантность. Под толерантностью понимается допустимое качество, пределы, в рамках которых это качество укладывается с заданной вероятностью. Пользователь должен получать информацию в виде, доступном для восприятия без дополнительной интерпретации и в то же время достаточно надежном для принятия решений.
Репрезентативность (относительность соответствия). Любое явление, факт или сущность должны соответствовать своим оценкам как с точки зрения средств измерения, так и с точки зрения точности и времени оценки, интересов конкретного пользователя. Для управленческого учета имеет ценность информация о стоимости обязательств с накопленными процентами, рыночная стоимость имущества, ликвидная стоимость векселей, основных средств и т.д. Кроме того, необходимо учитывать «вес» ликвидности. С другой стороны, те же обязательства и имущество могут оцениваться в различной валюте.
4. Система должна обеспечивать надежную защиту информации.
Задавайте вопросы нашему консультанту, он ждет вас внизу экрана и всегда онлайн специально для Вас. Не стесняемся, мы работаем совершенно бесплатно!!!
Также оказываем консультации по телефону: 8 (800) 600-76-83, звонок по России бесплатный!
• парольная система разграничения доступа к данным и функциям;
• многоуровневая система защиты данных, включающая средства авторизации вводимой и корректируемой информации;
• регистрация времени ввода и модификации данных, протокол удалений;
• программно-аппаратные средства криптографической защиты данных, сертифицированные ФАПСИ.
5. Целостность. Так как компания имеет сложную не только организационную, но и территориальную структуру, необходима реализация ИС с возможностью решения задач удаленного доступа и работы в распределенных сетях.
Для пользователей ИС большое значение имеет возможность консолидации информации на уровне:
• предприятий — для объединения информации филиалов, дочерних компании, предприятий, входящих в холдинг, и т.п.;
• отдельных задач;
• временных периодов — для анализа изменения тех или иных показателей за период, превышающий отчетный, и т.д.
6. Актуальность. Информационная система — это система постоянно развивающаяся в силу как влияния внешних факторов (например, постоянных изменений в законодательстве), так и изменения бизнес-функций предприятия, поэтому необходимо наличие инструментальных средств адаптации и сопровождения системы:
• изменение структуры и функций бизнес-процессов;
• изменение информационного пространства (изменение структуры, добавление/удаление БД, связей, индексов и т.п.);
• изменение интерфейсов ввода, просмотра и корректировки информации;
• изменение организационного и функционального наполнения рабочего места пользователя;
• изменение требований к вычислительным ресурсам.
Важно обеспечить обмен данными между ИС и другими программными продуктами, ранее функционирующими на предприятии.
7. Надежность. Информационная система — это сложная система, и надежность ее функционирования не может быть обеспечена без специальных средств анализа состояния системы в процессе эксплуатации:
• анализ архитектуры баз данных;
• анализ алгоритмов;
• анализ статистики количества обработанной информации (количество записей, документов, проводок; объем дисковой памяти);
• журнал выполненных операций;
• список работающих станций, внутрисистемная почта и т.д. Вложение средств в создание ИС надо рассматривать как долговременные инвестиции. В свете этого большое значение приобретает уровень и качество обслуживания, предоставляемого разработчиком. Обязательным условием является локализация информационной системы как функциональная (учет особенностей российского законодательства и системы расчетов), так и лингвистическая (интерфейс, система помощи и документация на русском языке).
Классификация систем управления предприятиями важна для определения места той или иной системы на рынке и корректного сопоставления ее с другими системами. Главным фактором для классификации систем управления является показатель того, насколько та или иная система влияет на бизнес предприятия. С этой точки зрения можно выделить четыре типа систем управления.
Система типа А не является системой управления предприятием и включена в классификацию для общности. Примерами таких систем являются, например, бухгалтерские системы.
Системы типа В обеспечивают процесс управления информацией, но не содержат в себе никаких компонентов для практической реализации этого процесса. Все что связано с управлением осуществляется вне таких систем. Примером такой системы может служить система, обслуживающая склад и торговый зал розничного магазина.
Системы типа С имеют в своем составе компоненты управления и средства определения правил работы, давая возможность выбора той или иной предопределенной схемы. Такие системы поддерживают весь управленческий цикл: планирование, организация деятельности, исполнение и анализ результатов. Однако при изменении внешних условий бизнеса или возникновении новых задач могут отсутствовать подходящие реализации бизнес-схем. Примером таких систем являются системы управления качеством, управления персоналом, сервисного обслуживания, управления дистрибуцией и др.
Системы типа D позволяют динамически изменять хозяйственные схемы без остановки работы всей системы. Начав процесс по одной схеме, можно завершить его по новой, которая была разработана под изменившиеся условия.
При увеличении сложности и широты охвата функций предприятия системой возрастают требования к технической инфраструктуре и компьютерной платформе. Все без исключения производственные системы разработаны с помощью промышленных баз данных. В большинстве случаев используется технология клиент-сервер, которая предполагает разделение обработки данных между выделенным сервером и рабочей станцией. Технология клиент-сервер оправдывает себя при обработке больших объемов данных и запросов, так как позволяет оптимизировать интенсивность передачи данных по компьютерной сети.
Управление изменениями информационных систем
Управление изменениями ИС — это не те операционные изменения, которые требуются для улучшения повседневной работы пользователей ИС, хотя и они важны. Операционные изменения относятся к вопросу поддержки ИС и будут рассмотрены далее.
Существует несколько подходов к управлению изменениями ИС. Это, прежде всего проектирование архитектуры ИС и ее трансформации в зависимости от изменений бизнеса. И другое направление — интеграция систем, входящих в КИС.
Проектирование архитектуры
Институт разработки архитектуры предприятий IFEAD (Institute for Enterprise Architecture Development) обобщает основные руководящие принципы дисциплины архитектуры предприятия следующим образом: «Нет стратегических прогнозов — нет архитектуры предприятия». Другими словами, архитектура предприятия сегодня — это система бизнеса завтра. Важный аспект этого утверждения заключается в том, что архитектура предприятия — это целостная дисциплина, которая объединяет элементы бизнеса и технологии исходя из общего стратегического прогноза предприятия.
Дисциплина «Архитектура бизнеса» считается «относящейся к бизнесу»; она описывает, как он работает. Хотя вряд ли можно достичь согласия по поводу того, какие компоненты следует включить в инфраструктуру архитектуры бизнеса. Принято считать, что значимыми аспектами в этой предметной области являются аспекты Процесс и Информация (Process and Information), Организация (Organization) и Производительность (Performance). Каждый из этих компонентов сам по себе очень важен и включает несколько предметных областей.
Компоненты Процесс и Информация, вероятно, являются основными для архитектуры бизнеса, поскольку они определяют, описывают и классифицируют бизнес-процессы и опорные структуры, которые составляют бизнес-модель организации. Этот компонент включает также группу связанных объектов, таких как удобство применения и доступность. У каждой организации, конечно, есть различные бизнес-процессы, структуры, технологические потоки и т.д. Точно так же какая-либо организация может иметь что-то особенное в своей модели бизнес-процесса, что поднимает ее над конкурентами, в то время как другие организации продолжают вести борьбу в этой отрасли.
Компонент Организация относится к структуре и конструированию методов работы, а также к стилю работы в организации. Объекты, которые взаимодействуют с этим компонентом, включают структуру организации, продукты и услуги, которые производит бизнес, и т.д.
Производительность бизнеса — это компонент, связанный с управлением, объединяющий объекты, которые определяют и измеряют эффективность организации. В него входят такие объекты, как производительность, бизнес-риски и другие связанные объекты.
Основным интересом предметной области архитектуры предприятия является само предприятие — идентификация, спецификация и расстановка приоритетов требований бизнеса. Рассмотренные точки зрения и модели, взятые в контексте инфраструктуры архитектуры предприятия, решают определенный круг текущих и потенциальных проблем.
Относительная сложность реализации программы архитектуры предприятия зависит от таких факторов, как уровень решимости организации, доступность ресурсов и управления, размер и сложность бизнес-модели организации, а также гибкость организации. Правда заключается в том, что многие организации просто не способны одновременно реализовать программу архитектуры предприятия и управлять ею, поэтому будет лучше сконцентрироваться на менее перспективных методах улучшения процесса, которые отражают скорее эффекты, чем эффективность.
Существуют два общих подхода к реализации архитектуры предприятия, которые примерно соотносимы с двумя разными видами доступных инфраструктур.
Первый подход проецирует организационные артефакты и процессы на мета-структуру инфраструктуры. Этот подход хорошо работает в организациях, которые преуспели в моделировании. Организации, предпочитающие такой подход, обычно выбирают схему Захмана или эквивалентную инфраструктуру. Одна из опасностей такого подхода заключается в том, что такая инфраструктура может ограничивать творческую инициативу и вносить в процесс реализации архитектуры предприятия элемент бюрократизма. Еще одной проблемой этого типа инфраструктуры является серьезная нехватка инструкций по реализации.
Второй подход строится на убеждении, что программа архитектуры предприятия должна управляться процессами. Поскольку этот подход концентрируется, в первую очередь, на деятельностях, а не артефактах, он может быть более простым для понимания и связи с существующей рабочей средой, а также методиками и методами решения.
Хотя оба подхода имеют свои «за» и «против», можно выбрать компромиссное решение — использовать процесс, управляемый деятельностью в целом, а в качестве опорной структуры или в целях анализа применять мета-инфраструктуру.
Методологии предприятия и инфраструктуры, которые существуют сегодня, значительно отличаются по диапазону проблем, которые они решают, и подходам, которые они используют. Вот некоторые из хорошо известных инфраструктур: 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 пользовались менеджеры не выше среднего звена.
В соответствии с триединой задачей «PLM по-новому» можно разделить на три взаимосвязанные составляющие управления жизненным циклом:
• определения изделий (интеллектуальные активы предприятия);
• производства (материальные активы предприятия);
• операционной поддержки.
Образно эти циклы можно представить в виде трех спиралей, накрученных одна поверх другой. Первичным является жизненный цикл управления интеллектуальными активами; он начинается с оценки пользовательских требований, выработки концепции продукта, а завершается, когда предприятие полностью отказывается от продукта, в том числе и от его сервисной поддержки.
Если перевести обсуждение в категории управления знаниями, то одной из важнейших задач в этом цикле является перевод знаний, скрытых в умах всех занятых в нем сотрудников, в явные знания, заключенные в форму документации на механические изделия, электронные компоненты, программное обеспечение, описание сервисных процедур и т.д. Процесс перевода и накопления непрерывен, он служит формированию интеллектуального капитала компании.
Поверх первого цикла накручивается второй — производственный; он включает все, что связано с выпуском и распределением выпущенной продукции. Основными приложениями, реализующими функции этого цикла, являются системы управления ресурсами предприятия (MES, MRPII/ERP). Внешний, операционный цикл поддерживают системы управления финансами, кадрами и другими ресурсами (CRM, SCM и пр.).
Одно из наиболее полных определений PLM состоит из четырех пунктов:
• стратегический подход к бизнесу, предлагающий непрерывный набор бизнес-решений, который поддерживает коллаборативный режим создания, управления, распределения и использования определения изделий (интеллектуальных активов предприятия);
• поддержка «расширенного представления о предприятии» (extended enterprise), в том числе поддержка процессоров проектирования, пользователей и партнеров;
• действие во времени от момента рождения концепции изделия до снятия его с производства и окончания сервисного периода;
• интеграция людей, процессов, систем и информации.
Важно подчеркнуть, что в этом определении PLM рассматривается не как часть или части технологий, а как бизнес-подход, цель которого состоит в поиске ответов на вопросы «Как работает бизнес?» и «Что создается?».
На основании этого определения выделяются три основные концепции PLM:
• возможность универсального, безопасного и управляемого способа доступа и использования информации, определяющей изделие;
• поддержание целостности информации, определяющей изделие, на протяжении всего его жизненного цикла;
• управление и поддержка бизнес-процессов, используемых при создании, распределении и использовании подобной информации.
Эти определения позволяют расширить представления области действия PLM на нетрадиционные изделия. Изначально PLM применяли к изделиям, имеющим штучное представление, но сегодня в качестве изделий можно рассматривать также программное обеспечение, различные формы услуг (от информационных до бытовых), продукцию нефтегазового комплекса и т.д.
Необходимо рассматривать PLM не только как возможность повысить эффективность капиталовложений. Главное достоинство этого бизнес-подхода — в возможности увидеть проблемы производства в целом (360degree view of the product). Он позволяет интегрировать всех участников жизненного цикла изделия — от инженеров до вспомогательных служащих.
Поддержка информационных систем
ИТ-среда постоянно изменяется в ответ на изменение деловых потребностей, для повышения уровня доступности и введения новых технологий, а также в связи с естественным развитием бизнеса. Кроме того, ИТ-среда является чрезвычайно сложной, характеризующейся наличием многочисленных взаимозависимостей, учет которых становится все более и более важным для самого существования компании. По этим причинам организации нуждаются в использовании регламентированного процесса, который позволил бы вводить в эту среду необходимые изменения, практически не нарушая при этом нормального функционирования. Именно для этой цели предназначен процесс управления изменениями, один из самых востребованных процессов 1TIL.
Этот процесс охватывает организационные и инфраструктурные изменения, касающиеся аппаратных средств, программного обеспечения, системных компонентов, сервисов, документов и процессов, иными словами, всего того, что было преднамеренно введено в ИТ среду и может затрагивать ее функционирование.
Назначением процесса управления изменениями является предоставление возможности пользоваться регламентированным процессом для внесения требуемых изменений в ИТ-среду с минимальными нарушениями в ходе продолжающейся эксплуатации.
Для достижения этой цели в процессе управления изменениями решаются описанные ниже задачи:
• Формальное инициирование изменения путем подготовки запроса на изменение (Request For Change — RFC).
• Назначение изменению приоритета и категории после оценки его срочности и его влияния на инфраструктуру или конечных пользователей. От этого назначения зависит скорость, с которой изменение должно быть рассмотрено, и маршрут, который оно пройдет для его утверждения.
• Организация эффективного процесса передачи RFC менеджеру изменений и консультативному совету по изменениям (Change Advisory Board — CAB) для утверждения или отклонения изменения.
• Планирование развертывания изменения; состав этого процесса может изменяться в широких пределах и включать проведение оценок на ключевых промежуточных этапах.
• Работа с процессом управления релизами, которая входит в состав процесса управления изменениями и служит для управления релизами и развертывания изменений в производственной среде.
• Контроль достижения целей изменения, которые были перед ним поставлены, и определения того, следует ли оставить изменение в силе или отменить его.
В контексте управления изменениями само изменение определяется как любая модификация (в части аппаратных и программных средств, системных компонентов, сервисов, документов или процессов), которые сознательно вводятся в ИТ-среду и могут повлиять на соблюдение соглашения об уровне сервиса (Service Level Agreement — SLA) или оказать другое воздействие на функционирование среды или одного из ее компонентов. Изменения могут быть либо постоянными, либо временными. Они могут предусматривать замену текущей версии компонента (новым компонентом или модифицированной версией компонента) или предусматривать инсталляцию полностью другого компонента или удаление устаревшего.
Все изменения, подпадающие под это определение, постоянные или временные, новые или пересмотренные, должны быть предметом действия процесса управления изменениями. Управление изменениями должно распространяться на все изменения в ИТ-среде.
Это важно, поскольку изменения могут повлечь за собой описанные ниже последствия:
• Повлиять на работу многочисленных пользователей.
• Потенциально нарушить функционирование сервисов, важных с точки зрения решаемых задач или осуществления функций бизнеса.
• Повлечь за собой необходимость модификации аппаратных средств (таких как серверы или сетевое оборудование) или программного обеспечения.
• Затронуть данные, хранимые в ИТ-системах (это зависит от типа данных, например, обновление прейскуранта на веб-узле электронной коммерции должно контролироваться процессом управления изменениями, а обновление информации о заказчике в базе данных компании не должно контролироваться таким образом).
• Повлечь за собой модификации в эксплуатационных и технологических процессах, которые отразятся на многочисленных пользователях.
В основе процесса управления изменениями лежит потребность во внесении изменения, которая может быть обусловлена необходимостью внесения усовершенствования или выводом из эксплуатации существующего сервиса, либо создания нового. В рамках контролируемого процесса управления изменениями все эти потребности влекут за собой создание запроса на изменение (Request For Change — RFC). Запрос на изменение представляет собой стандартный документ, в котором зарегистрирована вся относящаяся к делу информация по предлагаемым изменениям, начиная от основных фактов об изменении (например, если речь идет об изменении имени поля в системе базы данных) и заканчивая более подробной информацией, такой как дальнейшие последствия изменения (например, касающиеся систем, в которых обрабатывается поле с изменяющимся именем или по информации из этого поля формируется отчет).
Запрос на изменение должен обеспечивать возможность определить, в чем состоит изменение, чем оно обусловлено, кто затребовал изменение, когда, где и как оно должно быть проведено. В этом документе должно быть описано изменение, показано, какие усилия и кем должны быть предприняты для реализации изменения, метод реализации и затрагиваемые конфигурационные единицы. Этот документ включает также вспомогательную информацию о назначении изменения, описывает его влияние на организацию, содержит план отмены изменения на случай неудачи, а также сведения о стоимости изменения, в случае необходимости включает сведения о том, утверждено ли данное изменение лицами, ответственными за соблюдение бюджета организации, а также показывает, насколько срочным является предлагаемые изменения. Указанный документ должен также содержать достаточный объем информации, позволяющий менеджеру изменений быстро и точно оценить изменение на начальном этапе рецензирования, а затем снова вернуться к этому вопросу на этапах официального изучения в целях утверждения или отклонения.
Лицо, желающее внести изменение в любую часть ИТ-инфраструктуры (инициатор изменения), руководствуясь описанием процесса управления изменениями, начинает этот процесс с заполнения RFC.
Ниже перечислены события, которые обычно приводят к подготовке RFC:
• Предложен способ разрешения инцидента или проблемы.
• Пользователь или заказчик выразил неудовлетворенность, обратившись в службу связи с заказчиками (чаще всего в службу поддержки), или показатели говорят о низком уровне предоставляемого сервиса, что указывает на необходимость внести усовершенствования в систему сервиса.
• Предложено ввести в действие или удалить какую-то конфигурационную единицу (Configuration Item — Cl).
• Изменилась стратегия бизнеса, в связи с чем были уточнены требования к ИТ.
• Необходимость изменения сервиса продиктована вводом в действие новых или пересмотренных законодательных актов.
• Изменилось территориальное расположение предприятия.
• Появилась необходимость внести модификации в предоставляемые продукты или услуги с учетом действий поставщиков или подрядчиков.
Инициатор изменения может занимать должность, позволяющую ему предложить определенное изменение, но сам этот сотрудник не всегда бывает знаком непосредственно с ИТ-средой. В таких случаях необходимо назначить владельца изменения от ИТ-организации, который должен быть способен предоставить необходимую информацию о специфике технологии, которую должно затронуть это изменение, для качественного оформления RFC.
Составляя RFC, инициатор изменения должен по мере возможности предоставить не менее чем перечисленную информацию:
• Имя инициатора изменения, должность и контактную информацию.
• Описание изменения, т.е. полный отчет о характере изменения.
• Предложение, касающееся назначения изменению приоритета и категории, которое основано на имеющейся информации.
• Номер отчета о проблеме (Problem Report — PR), относящийся к любой проблеме, которая касается этого изменения, или номера инцидентов, если они известны.
• Описание и идентификация любых элементов, подлежащих изменению, включая идентификацию конфигурационных единиц.
• Причина для внесения изменения.
• Анализ затрат и результатов, связанных с изменением, и резолюция бюджетного органа, если она является необходимой.
• Последствия, связанные с отказом от реализации изменения, включая любые соглашения об уровне сервиса, риск нарушения которых может быть вызван этим отказом.
• Оценка воздействия и ресурсов, т.е. описание того, какие пользователи будет затронуты этим изменением и насколько значительным окажется его результат.
• Обозначение релиза, к которому относится изменение, и предлагаемый план реализации с обозначением временных этапов.
• План восстановления того положения, которое предшествовало внесению изменения, с описанием предпосылок принятия решения об отмене изменения и указанием контактной информации лица, принимающего решение.
• Описание влияния на бесперебойную работу компании и планы действий в чрезвычайных обстоятельствах.
• Риск, связанный с внесением изменения.
От инициатора изменения может также потребоваться предоставление вспомогательной документации, такой, как бизнес-оценка, анализ затрат и результатов или предлагаемый план реализации для менеджера изменений и других лиц, участвующих в процессе утверждения изменения.
Два элемента RFC в списке инициатора изменений (рекомендуемый или предлагаемый приоритет и категория изменения) заслуживают более подробного описания.
При рассмотрении определения приоритета часто возникает определенная путаница; например, в словарном определении указано: «Степень предшествования, при определении которой особое значение придается порядку значимости или безотлагательности».
В процессе управления изменениями безотлагательность определяется тем, насколько быстро требуется внести изменение на деловом предприятии.
Ниже перечислены четыре рекомендуемых уровня приоритетов:
• Экстренный приоритет. Таковым является изменение, которое, не будучи немедленно реализовано, оставит организацию подверженной огромному риску. Например, к изменению с таким приоритетом относится установка патча в системе обеспечения безопасности.
• Высокий приоритет. Изменением с таким приоритетом является изменение, важное для организации, которое должно быть вскоре реализовано. В качестве примера можно указать обновление, продиктованное вводом в действие новых требований законодательства.
• Средний приоритет. Изменение, которое должно быть реализовано в целях получения преимуществ в связи с модификацией сервиса. Например, обновление, применяемое между сменами версий в ответ на пожелания службы обратной связи с заказчиком.
• Низкий приоритет. Изменение, которое не является срочным, но может оказаться выгодным. Примером такого изменения может стать дополнение к профилю пользователя, которое предусмотрено в связи с пожеланиями, высказанными пользователями.
Эти уровни приоритетов определены в соответствии с наилучшими рекомендациями, выработанными в данной отрасти промышленности. Тем не менее, в зависимости от размеров организации, ее структуры и основополагающих SLA, существующих между ИТ-отделом и деловым предприятием, которое он обслуживает, организация может потребовать модифицировать эти определения приоритетов и ввести собственные определения. Например, в некоторых организациях установлена такая практика, что если какое-то лицо, желающее внести дополнение к своему профилю пользователя, работает в области, важной с точки зрения функционирования предприятия, то указанное изменение может рассматриваться как имеющее высокий приоритет. И наоборот, если такое же изменение затребовано представителем той части делового предприятия, деятельность которой постепенно сворачивается, то изменение может рассматриваться как имеющее низкий приоритет. Важно, чтобы каждая организация предусмотрела правильное использование этих приоритетов для своей собственной среды, поскольку от этих приоритетов зависит, когда и как должно быть реализовано изменение. Приоритеты определяют также порядок рассмотрения запроса на изменение.
Однако важно отметить, что изменение с экстренным приоритетом отличается от изменений с другими приоритетами тем, что в нем используется другой маршрут прохождения через процесс оценки в целях наискорейшей реализации этого изменения. Поэтому данный приоритет зарезервирован только для тех изменений, которые, не будучи реализованными в срочном порядке, могут серьезно повлиять на снижение уровней сервиса или привести к большим расходам для компании. Количество экстренных изменений должно быть сведено до абсолютного минимума, поскольку с их реализацией связан повышенный риск; качественная практика планирования не может быть заменена экстренными изменениями.
Итак, приоритет изменения указывает, насколько срочно должно быть реализовано затребованное изменение, а категория изменения используется для определения того, насколько рассматриваемое изменение влияет на инфраструктуру, пользователей или на компанию в целом. Например, представляют интерес вопросы о том, повлияет ли изменение на работу одного пользователя, отдела или каждого пользователя организации. Повлечет ли за собой внесение этого изменения обновление одного коммутатора или полную реконструкцию сети? Категория изменения определяется в результате анализа ответов на подобные вопросы.
Как и в случае приоритетов, решение о том, как должны подразделяться на категории отдельные изменения, определяется потребностями конкретной организации.
В качестве рекомендации ниже приведены определения категорий, которые эффективно применяются во многих разных организациях:
• Крупное изменение. Изменение с массовым влиянием. Например, к этой категории относятся изменения в рамках отдела или корпорации или же изменение в масштабах всей сети либо всего сервиса.
• Значительное изменение. Изменение, эффект которого является широким, но не массовым, например, изменение, касающееся одной из групп в отделе или конкретной группы конфигурационных единиц.
• Мелкое изменение. Изменение, касающееся небольшого количества лиц или конфигурационных единиц, например, изменение в настройке принтера, который используется в отделе, состоящем всего из нескольких сотрудников.
• Стандартное изменение. Изменение, которое уже выполнялось прежде и входит в состав практики эксплуатации данного делового предприятия, например, изменение профиля пользователя. Как и в случае приоритета изменения, при назначении категории изменения необходимо учитывать специфику конкретной организации. В частности, изменение, затрагивающее определенный отдел, может рассматриваться как крупное в одних организациях, но считаться относящимся к стандартной категории в другой организации, в которой аналогичный отдел рассматривается как менее важный. То же самое касается изменений в процедуре предоставления определенных сервисов или применения определенных продуктов.
Одной из категорий изменений, рассматриваемых в настоящем документе, которая требует особого внимания, является стандартная категория изменений. Стандартные изменения находятся в нижней части шкалы категорий, поскольку их значимость с точки зрения влияния на работу пользователей или на функционирование инфраструктуры является низкой. Усилия, необходимые для реализации стандартных изменений, также относительно малы и в соответствии с этим не столь высок связанный с ними риск отрицательного воздействия на среду.
Как правило, консультативный совет по изменениям (Change Advisory Board — CAB) заранее определяет набор стандартных изменений и стандартных процедур для их реализации. Утверждение решения об использовании такого набора стандартных изменений может предоставляться автоматически, без необходимости проведения голосования в САВ или получения разрешения от менеджера изменений, что позволяет ускорить прохождение через процедуру утверждения изменений. Но в качестве стандартных должны рассматриваться только такие изменения, которые относятся к заранее определенному стандартному набору. К примерам стандартных изменений относятся регулярное плановое сопровождение, часто выполняемые задачи администрирования (такие как изменение профиля) и менее значимые запросы на предоставление сервиса.
После утверждения RFC (с использованием соответствующего маршрута, в котором учитывается его приоритет и категория) этот запрос передается в фазу разработки изменения. В данной фазе осуществляются шаги, необходимые для планирования изменения, разрабатываются средства осуществления этого изменения (например, подготавливается новый код или выполняется настройка конфигурации нового аппаратного обеспечения), после чего все необходимые данные передаются в процесс управления релизами для развертывания изменения в производственной среде.
Чтобы иметь возможность определить, было ли развернутое изменение эффективным и позволило ли достичь желаемых результатов, необходимо контролировать изменения в производственной среде. Если изменение является небольшим, то такой контроль может предусматривать лишь проверку достижения желаемых функциональных возможностей. А применительно к более значительным изменениям может потребоваться контролирование информации о сети и сервере, а также показателей производительности, журналов событий или значений времени отклика.
После сбора достаточного объема результатов контроля, позволяющего определить эффективность изменения, необходимо провести оценку после реализации. Продолжительность интервала времени между реализацией изменения и подготовкой оценки зависит от величины проведенного изменения и оттого, насколько быстро может быть измерен эффект от изменения.
Для проведения эффективных изменений НС необходимо обеспечить исполнение ролей в рамках данного процесса.
Статью подготовил категорийный менеджер по работе с ключевыми клиентами Умберг Эмиль Дмитриевич. 
