Информационный менеджмент

Подготовить лекционный материал к экзамену по дисциплине. Лекционный материал представлен 6-ю темами, содержащихся в 6-ти rtf-файлах Вопросы к экзамену представлены ниже. ВОПРОСЫ К ЭКЗАМЕНУ по дисциплине «Информационный менеджмент» 1. Задачи дисциплины «Информационный менеджмент» К основным задачам информационного менеджмента относятся: 1. Формирование технологической среды ИС. Проблема формирования технологической среды вызвана тем обстоятельством, что в настоящее время рынок средств информатизации (вычислительной, периферийной, коммуникационной техники (Hardware), а также программных информационных и сервисных средств (Software)) чрезвычайно насыщен, поэтому имеется множество вариантов формирования технологической среды ИС, среди которых необходимо найти оптимальный. 2. Развитие информационной системы и обеспечение ее обслуживания. Развитие и обслуживание ИС взаимно обусловлены: потребность в постоянном развитии приводит к необходимости роста обслуживания, а рост обслуживания отягощает их же развитие. В связи с этим возникают такие задачи менеджмента мониторинг производительности и качества ИС, стратегические решение по созданию/модернизации ИС и пр. 3. Планирование в среде ИС. Как известно, существуют стратегические задачи планирования и задачи оперативного планирования. Глобальная стратегическая цель информационного менеджмента состоит в обеспечении возможно большего вклада ИС в цели предприятия по основной деятельности через использование ИТ. Цели, определяемые на стратегическом уровне, реализуется на оперативном уровне ИМ. 4. Формирование организационной структуры в области информатизации. Внутренняя организация информационных служб до последних лет подчинялась, прежде всего, решению внутренних задач создания развития, обслуживания и эксплуатации ИС. Однако техническая и технологическая децентрализация, появление АРМ, заставляют вносить коррективы в функции и задачи информационной службы. Наряду с внутренней организацией изменяется также уровень вхождения подразделений по обработке информации в иерархию предприятий. 5. Использование и эксплуатация ИС. Эту задачу можно считать краеугольной задачей ИМ, поскольку эффективное использование и обеспечение работоспособности всех средств информатизации является основой решения всех остальных задач ИМ, и в свою очередь, успешная эксплуатация ИС зависит от оптимального решения всех задач ИМ. 6. Формирование инновационной политики и осуществление инновационных программ. Сфера обработки информации является динамичной и быстро изменяющейся областью. Чтобы новые возможности обработки информации сделать полезными для предприятия, необходимо предусмотреть постоянные инновации в этой сфере. 7. Управление персоналом в сфере информатизации. Главной задачей управления персоналом является повышение квалификации работников в сфере информатизации. Это касается не только информационных работников, но и всего персонала предприятия. 8. Управление капиталовложениями в сфере информатизации. Задачи эффективности капиталовложений в ИТ являются весьма актуальными потому, что затраты здесь, как правило, весьма значительны, доходность не очевидна, поскольку ИТ не могут оказывать прямого воздействия на эффективность основного производства. Их эффективность обычно связывают с улучшением процессов управления организации, которые уже непосредственно оказывают влияние на эффективность производства. Информационный менеджмент – это управление созданием и использованием информации в интересах основной деятельности организации. При этом можно выделить две крайние стратегии: минимизацию затрат на ИС и максимизацию отдачи от ИС. 9. Формирование и обеспечение комплексной защищенности информационных ресурсов. Проблема обеспечения защищенности данных (против потери или порчи), а также требования правовой охраны данных (защита от несанкционированного доступа), являются уже классическими требованиями к любой ИС. ИС должны быть защищены и от технических отказов, и от технологических нарушений при эксплуатации. 2. Связь ИТ-стратегии и бизнеса. Проблемы, решаемые ИТ-стратегией. Области и инструменты ИТ-стратегии. Информационные технологии только тогда значимы для бизнеса, когда необходимы для поддержки конкурентоспособной стратегической инициативы, позволяющей достигнуть значимых результатов для компании. Следовательно, основой ИТ-стратегии должна являться бизнес-стратегия организации, именно такая связь позволяет организации наиболее четко и эффективно использовать информационные технологии. Процесс разработки ИТ-стратегии должен состоять из последовательности таких этапов, как знакомство с бизнес-стратегией, сбор информации о состоянии дел организации в области ИТ, проведение анализа соответствия ИТ поставленным стратегическим целям бизнеса и, в конечном счете, формулировка списка ИТ-проектов. ИТ-стратегия должна предлагать решения проблем, которые можно разделить на следующие сегменты: ◦ программные комплексы и системы, предназначенные для оптимизации и повышения эффективности бизнес-процессов; ◦ технологическая инфраструктура: компьютерная, сетевая, телекоммуникационная, прочая электронная техника в комплекте с системным ПО; ◦ ИТ-службы (отделы информатизации), включая цели, задачи, методы и принципы организации их деятельности. Все эти задачи возлагаются на информационные отделы (ИТ-службы) предприятий, деятельность которых можно разделить на следующие фундаментальные два аспекта: 1. создание и управление приложениями (прикладными системами) и 2. эксплуатация инфраструктуры. Такое фундаментальное разделение обязанностей связано с различием в деятельности по созданию систем и сопровождению систем. Каждая из групп имеет свои цели: ◦ приложения определяют то, как выполняется работа, поэтому разработка приложений тесно связана с основным бизнесом компании или деятельностью государственной организации, а знание приложений – это, прежде всего, понимание бизнес-процессов; ◦ эксплуатация инфраструктуры – деятельность, относительно слабо связанная с ключевыми функциями (бизнесом) организации, сфокусированная в основном на технологиях. ◦ При разработке стратегии необходимо учитывать, каким образом новые ИТ повлияют на сложившуюся информационную инфраструктуру, каким образом будут в нее интегрированы, а также необходимо проводить финансовую оценку этих нововведений. Предлагается следующая модель стратегии информационных технологий, иерархически увязывающая все основные элементы построения стратегии информационных технологий Рисунок 1. Элементы стратегии информационных технологий Модель представлена иерархической структурой, на верхнем, корневом, уровне которой располагается бизнес-стратегия. Этот факт подчеркивает еще раз то, что основой стратегического планирования ИТ является именно бизнес-стратегия, независимо от того, существует ли она в явном виде или нет. Содержание стратегии ИТ состоит из: стратегии изменения портфеля прикладных систем предприятия (план изменения приложений) и стратегии развития процессов управления ИТ-ресурсами предприятия. Наличие двух стратегий объясняется тем, что отделы информационных технологий (ИТ-службы) имеют две принципиально отличных области деятельности, поэтому руководству следует использовать разные критерии для оценки каждого из этих направлений деятельности. По-разному оценивается и их экономическая эффективность: 1. приложения как элемент стратегии ИТ – это зона ответственности бизнеса. Основой функционирования организации являются бизнес-процессы, которые поддерживаются прикладными системами. Руководство компании должно оценивать стратегию в области прикладных систем с точки зрения качества и результативности поддержки ключевых функций бизнеса; 2. управление ИТ-ресурсами сфокусировано на сегодняшней, ежедневной эксплуатации инфраструктуры. Бизнес-руководство оценивает стратегию в области ИТ- инфраструктуры с точки зрения максимальной отдачи при минимальных затратах. Для разработки стратегии используются два ключевых инструмента: архитектура информационных технологий предприятия и финансовые инструменты. Архитектура обозначает решения, связанных с ИТ, в то время как финансовые инструменты используются для оценки возможных решений, связанных с реализацией стратегии, т. е. это инструменты планирования и реализации. Чисто финансовые инструменты (ROI, ROA), а также «смешанные» типа TVO (Total value of Opportunities – ценность возможностей для бизнеса) – это тот «язык», который должен использоваться для поддержки принятия решений. Оба инструмента могут быть сформулированы на бизнес-языке, а значит, могут служить основой для совместного обсуждения стратегии ИТ бизнес-руководством и руководством ИТ-службы. Последним компонентом стратегии являются люди и стратегия в области сорсинга (использование внутренних и внешних ресурсов): эта часть стратегии ИТ связана с обеспечением ресурсами, необходимыми для реализации. 3. Проблемы стратегического планирования ИТ. Планирование обычно рассматривается в трех формах – стратегическое, тактическое, операционное в соответствие с горизонтами планирования. Ранее стратегия была определена как значимое долговременное влияние на темп роста, производство и доход организации. Стратегическое планирование систем подразумевает планирование использования ИТ для стратегических целей. Несколько основополагающих причин объясняют, почему планирование информационных систем так затруднительно. Ниже приводятся некоторые из них. Цели бизнеса и планирование систем должны быть взаимосвязаны Планы по стратегическим системам необходимо увязывать с целями бизнеса и поддерживать их. К несчастью, высшее руководство при разработке стратегии часто исключает директора по ИТ из участия в этом процессе. К счастью, директор по ИТ все чаще принимает участие в работе высшего руководства, вдобавок планирование систем становится разделяемой ответственностью с другими членами высшего руководства. Возникновение электронной коммерции и глобализации заставили высшее руководство осознать необходимость участия в планировании систем. Технологии быстро изменяются Как можно выполнять планы, если ИТ так быстро меняются? Ответ один – непрерывный мониторинг и планирование изменений технологий и того, как бизнес может использовать эти технологии. В процессах планирования, прежде всего, необходимо сформировать представление (видение) будущего, лучшего из доступных, на основе которого принимаются текущие решения. Затем необходимо проводить мониторинг технологий с целью определить, нуждается ли видение будущего в изменениях. После этого проводится оценка принятых решений. Для организаций особенно важно уделять внимание подрывным технологиям и инновациям. Иногда новая и недешевая технология мягко заменяет действующую. Классическим примером является Linux, вначале дорогая и уступающая в эффективности Unix и Windows NT, за счет постоянных улучшений завоевавшая значительную долю рынка операционных систем для серверов. В 2007 IBM объявила об использовании Linux в своих новых серверах. USB устройства – другой пример подрывной технологии. Многие предсказатели предупреждали, что IP телефония заменит использующуюся десятилетиями, традиционную телефонию. Результатом планирования здесь для менеджмента необходимость разглядеть восходящую инновацию с очень высоким технологическим потенциалом и подходящими приложениями для бизнеса. Компании больше нуждаются в портфолио, а не в проектах Бизнесу нужны интегрированные аналоговые или цифровые технологии, способные работать совместно. В проектном менеджменте результаты отдельных проектов не сочетаются друг с другом. Портфельный подход требует более профессиональных форм планирования, так как проекты оцениваются по более общим, а не только по их индивидуальным оценкам. Становится важным, как проекты подходят друг к другу, и как сбалансирован портфель проектов. Развитие инфраструктуры трудно финансировать Люди интуитивно понимают, что развитие инфраструктуры имеет ключевое значение. Однако, чрезвычайно трудно определить, какие средства необходимо выделить для развития или улучшения инфраструктуры. Часто такое финансирование должно делаться под большие прикладные проекты. Проблема тогда заключается в том, что необходимо совершенствовать приложения в течение длительного времени, так чтобы инфраструктура улучшалась также в течение длительного времени. С середины 1980-х компании с пониманием относятся к непрерывной последовательности больших инвестиций в инфраструктуру. Вначале было нужно перейти от мэйнфреймов к клиент-серверной архитектуре, чтобы совместно использовать корпоративные и настольные вычисления. Затем внедряли ERP, чтобы централизовать и стандартизировать данные с тем, чтобы каждый имел доступ к одной и той же информации. Затем нужно было создавать Web присутствие и дать каждому пользователю доступ к бэкофисным (обеспечивающим) системам. Теперь на компании давит необходимость внедрения Web сервисно-ориентированной архитектуры и создания наилучших образцов процессов. Советы директоров осознали необходимость финансирования таких огромных многолетних проектов для того, чтобы оставаться конкурентоспособными. Такие большие ставки увеличивают сложность систем планирования. Необходимость совместной ответственности Обычно легче что-то сделать самому, чем собирать коалицию для того, чтобы это сделать. Сегодня, это уже не так. Системное планирование, инициируемое и проводимое директором по ИТ , не оказывается таким эффективным, как проводимое при полном партнерстве руководителей высшего уровня. Системное планирование становится планированием бизнеса, оно дает не только технологический выход. Многие большие организации устанавливают Советы по информационным системам или комитеты, которые периодически пересматривают эффективность текущих стратегических планов, оценивают текущее технологическое окружение, разрабатывают ИТ стратегию, основанную на миссии учреждения и его целях. 4. Процесс стратегического планирования ИТ. Модель Carther Group. Традиционная стратегия разрабатывается в следующей последовательности (рис 1- 1. Руководители бизнеса разрабатывают стратегический бизнес-план, описывающий желаемые направления развития. 2. По этому плану работники информационных отделов создают стратегический план, описывающий как ИТ должны поддерживать этот бизнес-план. 3. Исполнительный план по ИТ создается для того, чтобы точно описать, как стратегический план по ИТ будет выполняться. Рисунок 2. Конечно, никто и никогда не относил задачи стратегического планирования к разряду простых и легких. Но при всей их сложности и комплексности они достаточно хорошо структурируемы и вполне решаемы. И если снова обратиться к зарубежной практике и мировому опыту, то они предлагают множество методик превращения неподъемных, на первый взгляд, проблем в стройные, взаимоувязанные и реализуемые схемы – благо, только в арсенале IBM Businеss Consulting Services насчитываются десятки методик целеполагания, архитектурного строительства, системной аналитики, benchmarking’а и т. п. Рассмотрим модель Gartner Group, идентифицирующую элементы бизнес-стратегии с точки зрения ИТ-стратегии. В соответствии с Gartner, количество элементов, определяющих ИТ-стратегию, может быть уменьшено до пяти областей: ◦ ИТ-инфраструктура. Все компоненты ИТ (аппаратное и программное обеспечение и комплектующие, сети), необходимые для обеспечения среды выполнения бизнес-процессов предприятия. ◦ ИТ-сервисы (эксплуатация). Как департамент ИТ обеспечит доступность ИТ-среды, какие услуги бизнес-подразделения получают от департамента ИТ на ежедневной основе. Наиболее общим определением ИТ-услуг для бизнес-подразделений является Соглашение об уровне обслуживания (SLA – Service-LevelAgreement). ◦ Портфель приложений определяет, как будет меняться имеющийся набор прикладных систем. ◦ Интеграции бизнес-процессов отвечает на вопрос, как будут обеспечены интеграция и взаимодействие различных систем между собой. Это особенно важно в связи с ростом объемов электронного взаимодействия с поставщиками, партнерами и клиентами и распространением практики использования внешних ресурсов. ◦ Сорсинг. Обеспечение выполнения стратегии внутренними и внешними для департамента ИТ ресурсами. Рисунок 3. - Две области ИТ-стратегии и пять определяющих элементов Рассмотрим, как эта методика соответствует приведенному выше определению ИТ стратегии, согласно которой информационная стратегия состоит из двух частей: стратегии изменения портфеля прикладных систем предприятия и стратегии развития процессов управления ИТ-ресурсами предприятия, определим, как обозначенные пять элементов соотносятся с двумя частями ИТ стратегии (рисунок 1-3). Для каждой из этих областей существует свое соотношение по влиянию, управлению и участию между бизнес- подразделениями и ИТ-службой. Так, наибольший «вес» бизнес-подразделения будут иметь при рассмотрении вопросов в области прикладных систем. Аспекты инфраструктуры ИТ-систем, интеграции и ресурсов находятся преимущественно в сфере компетенции ИТ-службы, а реализация ИТ-сервисов производится ИТ-службой или привлекаемыми ею поставщиками услуг с учетом интересов потребителей из подразделений бизнеса. 5. Возможная структура документа, описывающего стратегию ИТ Стратегическое управление информационными технологиями в большинстве российских организаций происходит, как правило, по следующей схеме: «Суммируя наблюдения аналитиков и экспертные мнения о типовых процедурах становления ИТ- хозяйств в большинстве российских компаний, можно сделать следующий вывод. На первом этапе (сразу же по получении хотя бы части абстрактно запрошенных ассигнований) происходит массированное техническое оснащение, через годик-другой закупается прикладное программное обеспечение, потом (причем не во всех случаях) устанавливается лицензионное системное ПО, параллельно происходит пополнение штата сотрудников и предпринимаются попытки разрешения нарастающего количества проблем с сопровождением постоянно конфликтующих между собой составных частей строящегося ИТ-здания, и только после того, как это сооружение приобретает более или менее четкие очертания и некоторую устойчивость, возникает вопрос о его пользе и продуктивности с позиций основного бизнеса. Распределение финансовых ресурсов в результате получается таким, что львиная доля затрат приходится на технику, существенно меньше – на ее поддержку, а уж остатки (которых, впрочем, почти не бывает) – на оценку эффективности и ее повышение». Для обоснования ИТ-стратегии предприятия структура предлагающего ее документа должна содержать разделы, отражающие причины ее возникновения, – потребности бизнес-стратегии организации; текущее состояние информационных технологий, их соответствие выдвигаемым бизнес-инициативам, новое, целевое состояние информационных систем, ИТ-инфраструктуры, процессов управления информационными ресурсами финансовые аспекты внедрения новых информационных технологий и пр. Описание стратегии целесообразно формировать в виде краткого документа, ориентированного, прежде всего, на пользователей, работающих в бизнесе. Пример возможной структуры документа приведен в следующей таблице: Таблица1.1 - Возможная структура документа «ИТ стратегия предприятия» Введение Цели работы, ограничения и подход Здесь кратко формулируется назначение документа, определяется его позиционирование для работы ИТ-службы и бизнес-подразделений, приводятся ссылки на другие документы (описание архитектуры, план проектов) Связь со стратегией бизнеса Здесь описываются внешние и внутренние условия, которые определяют направления развития бизнеса, цели бизнеса и основные инициативы. На основе бизнес-стратегии развития компании формулируются основные задачи информационных систем (что требуется) и ИТ-службы (как делать). Определяется позиционирование ИТ для бизнеса организации: например, является ли она конкурентным преимуществом или центром затрат. Здесь можно подчеркнуть роль перспективных информационных технологий для развития существующего бизнеса или создания новых бизнес-направлений Существующая организация дел в области ИТ Приводится краткое неформальное описание «верхних уровней» Архитектуры предприятия. Это могут быть уровни, связанные с бизнес- архитектурой и портфелем прикладных систем. Кратко формулируется оценка соответствия существующего состояния архитектуры требованиям бизнеса, основные проблемы ИТ. Может быть приведено резюме сравнения с конкурентами или с лучшими практиками Целевое состояние информационных систем Целевая архитектура предприятия (позиционирование / оценка / важность ) Для основных направлений бизнеса приводится резюме по развитию, сохранению или замене соответствующих прикладных систем. Этот раздел не предназначен для описания технических деталей Интеграция Резюме по организации взаимодействия с внешними системами (поставщики, клиенты), а также приложений между собой, созданию порталов и хранилищ данных и т. п. Инфраструктура При необходимости развития инфраструктуры приводится краткая характеристика направлений развития (модернизация серверов, создание глобальных сетей и т. п.) Целевая система управления ИТ-ресурсами Целевая система управления ИТ- ресурсами Основные направления совершенствования процессов управления ИТ, оценки качества и целевые показатели работы ИТ Организационные изменения Возможные изменения в структуре управления ИТ, роль директора по информационным технологиям. Организация стратегического управления ИТ Взаимодействие Реализация модели взаимодействия между ИТ-службами и подразделениями бизнеса Сорсинг Стратегия выбора исполнителей и поставщиков услуг. Развитие персонала внутренней ИТ-службы Финансирование Источники и порядок финансирования, используемые финансовые инструменты, организация принятия решений План перехода Укрупненный план перехода к целевой архитектуре информационных систем Интегральные характеристики ИТ-бюджета и списка проектов. Принципы выбора / ранжирования проектов и инструменты для их оценки Варианты и риски Возможные варианты стратегии в зависимости от объемов финансирования и вариантов развития бизнеса, анализ рисков. Оценка готовности организации к реализации данной стратегии Выбор проектов Классификация и список важнейших проектов на ближайшие 1-3 года, сгруппированных по категориям. Цель дать краткое неформальное описание в рамках одного сводного документа (цели, задачи, сроки), а также подчеркнуть вопросы взаимозависимости проектов 6. Новые тенденции в стратегическом планировании ИТ Традиционные технологии стратегического планирования ИТ основаны на следующих предположениях: ▪ Будущее можно предсказать ▪ Имеется достаточно времени, чтобы реализовывать планирование через три фазы (рис 1-2) ▪ ИС поддерживают бизнес и следуют за ним ▪ Высшее руководство знает все лучше, поскольку имеет более широкое представление о фирме ▪ Компанию можно представить как армию: Лидер отдает приказы, войска им следуют. Сегодня, благодаря Интернету, эти положения не кажутся больше истинными. Будущее менее предсказуемо Появление Интернета в бизнесе вызвало нескончаемые изменения, происходящие самым непредсказуемым образом. Поэтому стратегиям, которыми пользовались в прошлом, больше невозможно пользоваться. Непредсказуемым оказалось появление Amazon.com и eBay. Как только фирма включает Интернет в бизнес, так сразу же появляется новая модель бизнеса. Время на исходе Благодаря Интернету, время стало иметь значение. Компании больше не могут позволить себе роскошь планировать в течение года и несколько лет его выполнять. Более того, больше всего потребляющая время фаза планирования – внедрение ИТ – находится в самом конце, что означает, что отдел ИТ будет опаздывать в поддержке стратегии бизнеса с самого начала. Чтобы продвигаться быстрее, планирование внедрения ИТ необходимо действительно ставить во главу процесса стратегического планирования бизнеса. Более того, нужно все это делать быстрее, чем прежде. ИС уже не только поддерживают бизнес ИТ становятся платформой бизнеса. Аналитики отмечают, что ИТ могут обслуживать бизнес двумя путями. Первый – поддержка текущих или запланированных операций, которые они назвали его «настройка». Второй – использование систем на будущие способы работы, который они назвали «импульс». Чтобы исполнять вторую роль, ИС необходимо идти впереди бизнеса, чтобы демонстрировать возможности ИТ. По крайней мере, информационной службе и бизнесу необходимо вырабатывать стратегию вместе, не следовать старой модели бизнес впереди, информационная служба затем. Высшее руководство не может знать лучше Когда изменения происходят быстро и высшее руководство отдалено от передней линии бизнеса (взаимодействие с покупателями, партнерами, поставщиками), наличная стратегия, сформулированная высшим руководством, ограничена тем, что эти члены фирмы смогли извлечь самого существенного. Современный тренд продажи товаров и услуг на все более малых и малых нишевых рынках, даже индивидуальных, требует диверсифицированной стратегии. Это может быть сделано наилучшим образом теми, кто находится ближе всего к покупателю – если только не сами покупатели, потому что они лучше всего знают свою профессиональную среду. Следовательно, прежний вывернутый наружу подход к созданию стратегии должен быть трансформирован в подход «снаружи внутрь». Организация не похожа на армию Индустриальная эра планирования косвенным образом представляла компанию как армию. Приказы высшего руководства спускались вниз через всю организацию, чтобы быть выполненными войсками на передовой линии фронта теми, кто имел дело с покупателями. Эта метафора больше не является истинной. Рассмотрим в качестве примера реинжиниринг бизнес-процессов начала 1990-х. Руководители узнали, что их наказы по созданию больших изменений в бизнес-процессах, инициированных сверху, часто заканчивались катастрофой. Мало того, что проекты терпели неудачу, но также съедались ресурсы, сгорали работники, возникала неприязнь, и даже разрушались запасы ценных знаний компании, потому что опытные работники уходили. Социо-биологическое представление об информационной системе заключается в том, чтобы рассматривать систему как живую сущность, которая эволюционирует согласно собственной выгоде и способна мутировать. Ею не командуют, она может только направляться и обслуживаться. Возможности, предоставляемые этим системам должны быть таковы, что они смогут улучшать себя и свой мир. Современный подход «проб и ошибок» к планированию ИТ В прошлом высшему руководству требовалось время, чтобы четко сформулировать стратегию для всего предприятия. Во времена быстрых изменений и неопределенного будущего, что мы наблюдаем в настоящее время, такой подход становится рискованным. Когда предсказывать рискованно, способ продвигаться в будущее – шаг за шагом, используя подход «проб и ошибок». Это означает, чувствовать благоприятные случаи и возможности и быстро отвечать, проводя эксперименты. Такой подход может быть реализован в технологии управления проектами. 7. Управление портфелем ИТ-проектов Составным элементом разработки ИТ-стратегии и одним из этапов процесса управления стратегией ИТ является формирование программы (плана реализации) ИТ- проектов. Перед принятием такой программы необходимо предварительно определить критерии, которые должны применяться при выборе и утверждении проектов, а также провести оценку соответствия ведущихся или уже запланированных проектов создаваемой стратегии. Соответствующий процесс в рамках реализации стратегии обычно обозначается как управление портфелем ИТ-проектов (Portfolio Management). Принципы управления портфелем ИТ-проектов являются одновременно и инструментом принятия решений об инвестировании в проекты. Заметим, что в больших организациях отдельные проекты обычно группируются в проектные программы. Программа – это набор проектов, которые в совокупности составляют некоторую крупную инициативу. Примером такой инициативы может быть создание корпоративного хранилища данных, что требует реализации нескольких параллельных и связанных между собой проектов, которые к тому же могут выполняться различными внутренними подразделениями организации или с привлечением внешних субподрядчиков. Следует отметить, что проекты представляют собой более детальный, тактический уровень преобразований информационной системы. Поэтому сводить стратегию к оценке выполненных и набору новых проектов было бы неправильным. Сама стратегия определяет только направления и ограничения в реализации, в то время как проекты описывают детализацию выбранных путей. Еще один фактор связан с временными рамками – стратегия является относительно постоянной, непрерывной и периодически пересматриваемой, а каждый отдельный проект ограничен жесткими временными рамками. Таким образом, стратегия обычно сводится к определению общих принципов отбора проектов и конкретных практических инструментов, которые будут использоваться для поиска правильных компромиссов в области инвестиций в ИТ и принятия информированных решений даже в тех случаях, когда сами технологии трудны для понимания бизнес-руководителями. 1.6.1 Выбор приоритетов для инвестиций Существенной частью общего портфеля ИТ-проектов и ресурсов является портфель прикладных систем. Различают три типа различных прикладных ИТ-систем: базовые транзакционные (вспомогательные), дающие преимущества (информационные), инновационные (стратегические). Казалось бы, чем выше вклад в достижение бизнес- результатов и потенциальная отдача с точки зрения реализации бизнес-стратегий, тем выше должны быть объемы финансирования. Однако зависимости далеко не так очевидны. Большую часть в общем портфеле составляют базовые (обеспечивающие или вспомогательные) приложения, и именно здесь расходуется большая часть ИТ-бюджета. Отметим также, что достижение желаемого соответствия между бизнес-стратегией и имеющимся на предприятии портфелем ИТ-активов является "стрельбой по движущейся цели". Меняется среда, и соответственно меняются конкурентные стратегии в ответ на изменения рынка. Создание портфеля ИТ-активов (приложений, инфраструктуры) – длительный процесс, который реализуется через выполнение проектов. Цель состоит в том, чтобы ИТ-проекты задавали правильное направление в развитии всего портфеля ИТ- активов предприятия, максимизируя ценность портфеля с точки зрения бизнеса предприятия. Совокупный портфель ИТ-активов включает в качестве составляющих элементов как прикладные системы, так и технологическую инфраструктуру, а именно, следующие четыре компоненты: • базовые транзакционные прикладные системы; • информационные (дающие преимущества) прикладные системы; • инновационные (стратегические) прикладные системы; • инфраструктура. Рисунок 1.4 показывает типичное, среднее для различных типов предприятий и индустрий распределение расходов. Рис. 1.4. Распределение инвестиций по элементам портфеля технологий предприятия Из приведенных данных видно, что инвестиции в инфраструктуру (элементы, составляющие технологическую архитектуру) получают в среднем 54% от общих затрат на информационные технологии, т.е. более половины. Отсюда понятно, почему многие усилия в области построения архитектуры предприятия начинаются, на самом деле, с домена технологической архитектуры. В этой области есть максимальные возможности получения измеримых результатов в форме экономии затрат. На базовые транзакционные прикладные системы в среднем тратится 13% бюджета. Характерной особенностью этих систем является то, что дополнительные затраты на новые транзакции ничтожно малы, если система уже инсталлирована и имеется необходимая инфраструктура. Системы, которые мы отнесли к разряду информационных (дающих преимущества), очень часто используют возможности транзакционных систем и обеспечивают коммуникационные возможности и возможности по совместной работе сотрудников внутри и вне компании. Затраты на них составляют в среднем 20% от бюджета на ИТ. Ну и, наконец, на инновационные (стратегические) системы расходуется в среднем 13% бюджета. Эти четыре класса ИТ-активов имеют различные характеристики соотношения риск/отдача, при этом риски и, соответственно, отдача, минимальны у базовых транзакционных систем и более высоки у систем, дающих преимущества, и инновационных систем. Так, утверждается, что есть положительная статистическая зависимость между увеличением инвестиций в базовые транзакционные системы и таким важным финансовым показателем, как возврат на основные фонды (ROA – Return on Assets). В то же время компании, которые больше инвестировали в базовые транзакционные системы, имели меньший рост оборота. То есть, это инвестиции с относительно невысоким риском, но с достаточно надежной, хотя и не всегда фантастически высокой, отдачей. С другой стороны, компании, которые больше инвестировали в прикладные системы, дающие преимущества (информационные), имели более короткий цикл вывода новых продуктов на рынок, более высокое качество своих продуктов, способность более гибко менять цены. При этом эффективность таких систем оценивается как высокая, если они реализованы на уровне бизнес-подразделений, где они ближе к руководству, принимающему повседневные решения. То есть, проекты создания этого типа систем – более рискованные, и при этом эффективность их использования зависит от уровня организации остальных управленческих процессов. Инвестиции в инновационные (стратегические) прикладные системы преследуют цель получения конкурентных преимуществ. Получение и удержание таких преимуществ • непростая задача, и использование для этих целей информационных технологий не является чем-то экзотическим. Компании, которые инвестировали больше в инновационные системы, в среднем имели более высокую стоимость своей рабочей силы, им требовалось более продолжительное время для получения положительного возврата на основные фонды (только на третий год). Но для них был характерен более быстрый выход на рынок; их продукты и услуги воспринимались клиентами как более качественные и, следовательно, они готовы были платить больше; компании имели больший оборот в расчете на одного сотрудника. По своей природе, инвестиции в технологическую инфраструктуру являются крупными и долгосрочными и не имеют ценности сами по себе. Их ценность реализуется опосредованно через прикладные системы. Но в итоге, компании, которые инвестировали больше в инфраструктуру, имели в среднем более высокий показатель оборота в расчете на одного сотрудника и более высокие темпы роста этого показателя, особенно в индустриях, для которых характерны большие информационные потоки, таких как банковское дело или страхование. Для этих компаний был характерен в среднем более высокий процент продаж от новых продуктов и услуг, а также лучшие показатели в плане продажи смежных продуктов (cross-selling), что, видимо, объясняется интеграционными возможностями, обеспечиваемыми лучшей инфраструктурой. 8. Типы стратегического использования ИТ Обычно рассматриваются три типа стратегического использования ИТ в бизнесе: ▪ Работа, обращенная во внутреннюю среду: взаимодействие бизнес- служащие; ▪ Работа, обращенная во внешнюю среду: взаимодействие бизнес-клиенты; ▪ Работа, обращенная к смежникам: взаимодействие бизнес-бизнес. Рассмотрим примеры из прошлого для иллюстрации данного положения. В середине 80-х самой актуальной темой были вычисления конечного пользователя (взаимодействие бизнес - служащие). Отделы ИТ стремились помочь пользователям больше узнать о ПК и о том, как пользоваться языками программирования, такими как BASIC, Focus, электронными таблицами, для того чтобы писать свои собственные компьютерные программы. Затем стратегическое использование сфокусировалось на внешней среде использования ИТ для получения конкурентных преимуществ. Например, создавались программы для работы на фондовой бирже, в которых сочетались счёт капитала, его контроль, и накопление. При внедрении они завоевали громадную долю рынка, способствовало росту популярности таким образом, что другие брокерные организации стали испытывать трудности, поскольку новые программы создавали серьезное конкурентное преимущество. В 1990-х, стратегическое использование ИТ повернуло к внутреннему использованию к реинжинирингу бизнес-процессов. Не было намерения автоматизировать существующие процессы, но полностью перепроектировать деятельность предприятия. Идея была оценена, но попытки ее реализации провалились, потому что в них разглядели тонко замаскированные усилия по сокращению персонала. Внедрение ERP-систем было также нацелено на улучшение внутренних операций, в особенности в обеспечении единого источника данных в масштабе предприятия. В середине 90-х, когда потенциал Интернета становится очевидным, поставщики интернета преимущественно рассматривали свое использование, направленное во внешнюю среду, чтобы обрести конкурентное преимущество. Однако, множество фирм использовали Интернет технологии внутри, построив интранет, чтобы улучшить процессы компании. Часто первые версии использовали электронные формы в интранет, сопровождаемые автоматизированными производственными процессами (workflow). К концу 1990-х появилось использование Интернет для бизнеса – электронного бизнеса, в особенности в сфере торговли, электронная коммерция. В 2000-х стратегическое использование ИТ во внешней и внутренней среде продолжалось, но в стратегическом использовании акцент делали на связывании поставщиков, покупателей, других участников в единую стоимостную цепочку или экосистему бизнеса. Инновации реализовывались посредством интернет-компаний, на конкурентные вызовы ответили фирмы, обслуживающие своих клиентов в офисах. Таким образом конкурентное преимущество заключалось в повышении прибыльности традиционных операций посредством использования Интернет для более сплоченной работы со своими партнерами. В настоящее время конкурентное преимущество ИТ рассматривается в их возможности обеспечивать управление в сильно расширенном сложном бизнес- окружении. 9. Современные тенденции стратегического использования ИТ 1. Общим трендом формирования инфраструктуры остается поиск низкой цены. Компании ищут свободное ПО, чтобы сократить издержки производства, берут преимущества VoIP (голосовой Интернет протокол), чтобы уменьшить стоимость телекоммуникаций. Руководители, отвечающие за ИТ, вместо покупок дорогостоящей специализированной продукции переходят на покупки дешевой стандартной продукции, и этот феномен происходит все в больших и больших секторах ИТ индустрии. 2. Интернет по-прежнему рассматривается как главное стратегическое преимущество фирм. Его широкое распространение обеспечено тремя ключевыми компонентами, ускоривших сетевой (онлайн) бизнес: • Широкий доступ к общественным сетям • Стандартные коммуникационные протоколы • Стандартные пользовательские интерфейсы. Ранние системы, связывающие фирмы с их покупателями или партнерами по бизнесу, требовали частных вычислительных сетей с фирменными приложениями. Действительно, личная фирменная природа систем была ключевой стратегической ценностью. Высокая стоимость создания, тестирования и использования этих систем закрепляла за ними покупателей и создавала барьеры для попыток конкурентов воспроизвести их. Однако, высокая стоимость также ограничивала доступ к этой системе и ограничивала ее широкое использование; только большие фирмы могли себе позволить создание таких систем. ◦ В отличии от прежнего понимания Интернет-стратегий, обещавших процветание только тем компаниям, которые присутствуют в Интернете, в настоящее время предпочтительной является стратегия компаний с двойным присутствием на рынке: физическом и виртуальном (Интернет), и это приносит выгоду/рентабельность. Как говорит Майкл Портер, единственный способ подтвердить преимущества, которые дает Интернет, создать отличную от других стоимостную цепочку, которая предложит уникальную ценность. Эта цепочка должна быть сильно интегрирована, так чтобы потенциальные конкуренты должны будут воссоздавать всю систему, чтобы получить дубликат стоимостного проекта. Портер рекомендует использовать Интернет, чтобы дополнить свою стратегию, не заменять существующие способы обслуживания клиентов, не бросать существующие каналы обслуживания.. Например, компания торгующая более 800000 образцами продукции и имеющая склады по всему региону, имеет многоканальную стратегию обслуживания: ▪ Филиальная сеть: Покупатели могут посетить любой из 425 филиалов, чтобы сделать свой заказ в тот же день. Они имеют доступ к информационному сервису для покупателей, чтобы связаться с филиалом по телефону или факсу. ▪ Бумажный каталог. ▪ Покупатели могут заказать свыше 300000 продуктов через сайт и получить их, отгруженными непосредственно или заехав в местный филиал. Компания выяснила, что покупатели, делающие покупки через Web-сайт, также делают покупки по традиционным каналам, и таких покупателей на 9% больше, чем тех, кто не пользуется Web-сайтом. Она также открыла, что их материальное присутствие делает их виртуальное присутствие более ценным, особенно для покупателей, желающих быстрой доставки. Они делают онлайн заказы и отгружают их самостоятельно из ближайших складов, обслуживающих сайты. Такая комбинация позволяет снизить затраты для фирмы двумя путями: онлайн заказы менее дороги, чем заказы по телефону и отгрузка большими партиями в склады дешевле, чем небольшие индивидуальные поставки. Фирма предпочла продолжить публиковать бумажный каталог, после его размещения на Web-сайте, поскольку после этого появлялась большая волна онлайн заказов каждый раз как выпускали бумажный каталог. Два канала взаимно усиливают друг друга. 2.2. Интернет показывает, как формируются покупательские привычки экономикой большого бизнеса, такого как eBay, Google, Apple’s iTunes и Amazon. Интернет изменил культуру массового стимулирования потребительского интереса, давшего покупателям возможность исследовать специфические качества относительно того, что они хотят купить и что они покупают. Доминантным трендом является взрыв нишевых рынков, благодаря возрастающим возможностям поисковых машин и инструментов фильтрации, которые позволяют покупателям открывать и изучать то, что им интересно. В результате формируется экономика знаний, где информация управляет репутацией и позволяет расцветать нишевым культурам, экономика незаметно уходит от концентрации относительно небольшого количества «хитов» (главное направление (мейнстрим) товаров и рынков) во главе кривой спроса в направлении огромного количества ниш в хвосте (концевой части кривой спроса). 10. Формула конкурентного преимущества, создаваемого ИТ В начале - середине 2000-х на Западе разгорелась ожесточенная дискуссия, вызванная утверждением одного из экспертов (Николас Карр), что ИТ не имеют стратегического значения. Суть этого вывода состоит в следующем. ИТ являются инфраструктурными технологиями как железные дороги, электричество, телефон. Такая технология может создать стратегическое преимущество для отдельной фирмы только в начале своего жизненного цикла, когда эта технология дорога и рискованна, то есть единственный раз фирма может создать какую-то собственность, которую конкуренты не смогут легко скопировать. Как только инфраструктурная технология достигает конца своего развития, то есть она больше не является чей-то собственностью и больше не дорогая, она становится обычной, доступной каждому, и, следовательно, больше не создает конкурентного преимущества ни для одной фирмы. Согласно этому мнению, стратегические инвестиции должны обеспечивать дифференциацию, чтобы создать конкурентное преимущество. Инвестиции в обычную технологию не могут обеспечить (подкрепить) дифференциации, чтобы дать фирме конкурентное преимущество. Хотя ИТ необходимы в конкуренции, их недостаточно. Конкурентное преимущество идет от модели бизнеса фирмы, а не использования ИТ. ИТ становятся частью инфраструктуры бизнеса, следовательно, ее менеджмент должен изменяться. Успех зависит от защиты (надежности), а не от оплошности. Менеджмент ИТ должен стать «скучным» и сфокусироваться на трех областях: 2 Управление рисками. Фокусироваться на уязвимостях больше, чем на возможностях. Должно существовать множество рисков, потому что открытые системы более подвержены рискам, чем фирменные (собственные) системы. 3 Снижать затраты. Величайший риск - перерасход денежных средств, поэтому платить надо только за использование и ограничивать апгрейдинг (например, не проводить апгрейдинг ПК, без необходимости). 4 Оставайся позади лидеров технологий, но не слишком далеко позади, потому что эксперименты дороги. Откладывай инвестиции до тех пор, пока не появятся стандарты и лучшие практики, а цены снизятся. Совершать инновации, только тогда, когда риски низкие. Хотя инновации в области ИТ теряют возможность приобрести индивидуальное конкурентное преимущество, инфраструктурные технологии дают очень большую экономию и социальные преимущества для всех, если только она становится общей инфраструктурой. Это и есть то, чем станет ИТ. Это мнение оспаривалось многими профессионалами, приведем следующие доводы, высказанные оппонентами. А. Опыт использования дает три урока того, как стратегически использовать ИТ. • Ценность от ИТ возникает только тогда, когда они включены в пару с конкурентоспособными инновациями в бизнесе. Слишком многие компании не меняли свои практики в бизнесе, когда они внедряли ИТ. Именно поэтому исследования не показывают корреляции между распространением ИТ и ростом финансовых результатов. Руководители, рассматривающие ИТ как инфраструктуру, не изучают инновационные практики бизнеса, которые можно было бы применить, особенно по всему предприятию. • Экономический эффект от ИТ происходит от пошаговых улучшений, а не от огромных проектов по ИТ. Волны краткосрочных проектов по ИТ, выполняемых один за другим и связанных с изменениями бизнеса и метриками специфических рабочих характеристик, производят ценность. • Стратегическая дифференциация возникает в течение продолжительного периода времени. Это происходит от «способности постоянно делать инновации на основе эволюционирующих возможностей ИТ». Другие инфраструктурные технологии не поддерживают непрерывно совершенствующиеся практики бизнеса так долго, как это могут делать ИТ. Более того, они достигают совершенного дизайна очень быстро (например, стандартная ширина колеи на железной дороге). В сфере ИТ инновации в одной области (такой как, хранение данных или пропускная способность компьютерной сети) сочетаются с инновациями в других областях, реализуя новые возможности и новые поколения архитектуры. Новые навыки необходимы для этих новых архитектур. ИТ технологии не имеют еще доминантного дизайна, поэтому для отдельных фирм существует потенциал собственной дифференциации за счет использования ИТ – если их краткосрочные инициативы поддерживают долгосрочные цели. Б. Может быть в долгосрочной перспективе высказанное мнение и справедливо, но не по отношению к текущему положению ИТ. Фактически, мы сейчас находимся в золотом веке ИТ, в котором инновации ускоряются. ИТ может и не будут стратегическими лет через 20 или более, но сейчас, они все еще постоянно изменяются и могут обеспечивать дифференциацию. Для доказательства приведем только три: беспроводные технологии, миниатюризация, IP телефония. Совет следовать за лидером может быть оспорен, потому что задержка в использовании предложенной технологии, может привести к потере покупателей. Так, отели, которые предлагают доступ к беспроводному Интернету в настоящее время имеют стратегическую дифференциацию. Хотя эта дифференциация не может продолжаться долго, в настоящий момент эти отели имеют успешный бизнес. В.Оспаривается лежащее в основе данного утверждения предположение, что дефицитность является признаком ресурса, позволяющего поддерживать конкурентное преимущество. Однако, нет корреляции между дефицитностью и стратегической ценностью. Капитал является продуктом массового спроса, но отдача от капитала сильно различается. Имеет ли значение капитал? Конечно, имеет. Имеет значение не статус обычности ресурса, а способ, с помощью которого массовость используется, именно это определяет эффект. Капитал имеет значение. Талант имеет значение. ИТ имеет значение. Последнее, но не менее важное, менеджмент имеет значение. Фактически, менеджмент имеет значение тем больше, чем более распространенными становятся ИТ. Вездесущность ИТ не отвергает качества управления. Вместо того, чтобы сравнивать работу ИТ с работой электрических мощностей, автор должен был сравнить работу ИТ с работой фабрики. Но такое сравнение подрывает его предположение, потому что способ, по которому фабрика устроена и работает, будет в будущем оказывать влияние на ее конкурентоспособность. ИТ может серьёзно трансформировать экономическую инновацию, сегментацию и дифференциацию для большинства бизнесов. И именно в этом распознании лежат критические возможности ИТ. Есть такое правило: «Нельзя автоматизировать хаос». Особенно оно актуально для российских предприятий. Прежде чем внедрять ИТ, нужно подумать об организационной структуре, бизнес-процессах, корпоративной культуре. И только потом закреплять практику менеджмента в информационных системах. 11. Стратегическое использование ИТ внутри фирмы Смысл стратегического использования ИТ внутри предприятия был, и продолжает быть, в фокусировке на улучшении бизнес-процессов. Использование Интернета внутри не исключение. Интранет – собственная сеть компании, использующая технологии и протоколы Интернет, а, возможно, и сам Интернет. Сеть предназначена только для служащих, и подразделения используют ее для распространения политик и информации, обеспечения необходимыми формами, и даже для разрешения онлайн транзакций бывших бумажных процессов (таких как заполнение реквизитов счетов или изменение льгот / выплат). Приложения используют Web-интерфейс и доступны через браузеры; связь осуществляется через несколько протоколов, включая Hypertext Transfer Protocol (HTTP) для обращения к Web-сайтам, Hypertext Markup Language (HTML) для структурирования Web-контента, Transmission Control Protocol/Internet Protocol (TCP/IP) для работы сети. Результатом являются открытые системы, использующие дешевые доступные технологии. Когда все сделано правильно, выгоды от интранет весьма значительны: более широкий доступ к информации компании, менее дорогостоящее развитие системы, более низкая стоимость внедрения. Используя открытую системную архитектуру интранет, компании могут значительно снизить стоимость полного обеспечения информацией компании и надежность связи. Одной из наиболее важных характеристик интранет является то, что он поддерживает любые типы пользовательских устройств - от эксклюзивных рабочих станций до ПК, от портативного компьютера до мобильного устройства – также как существующие базы данных и прикладное программное обеспечение. Более того, инвестиции в электронную инфраструктуру масштаба всего предприятия значительно ниже, чем создание собственной сети. Компании нужны только сервера, браузеры и TCP/IP сеть, чтобы создать интранет. Если вдобавок компания желает использовать инфраструктуру Интернет, чтобы географически расширить свой интранет, единственным необходимым компонентом будет брандмауэр, межсетевой экран, который будет удерживать интранет от публичного доступа и поддерживать локальный доступ в Интернет. Наконец, поскольку интранет использует интерфейс браузера, пользователям не нужно дополнительно обучаться, как было бы в случае с другим программным продуктом. Вдобавок, благодаря HTML стандарту и наличию множества программных инструментальных средств, позволяющих легко создавать Web-страницы, пользователь легко может создавать свои собственные Web-страницы для достижения любых нужных ему целей. В результате все служащие являются потенциальными создателями сайтов, сокращая для отдела ИТ узкие места при соблюдении принятых в компании стандартов. Дополнительным выигрышем является то, что компании только нужно записать информацию в одном месте, где она будет содержаться до тех пор, пока больше не будет нужна сотрудникам, где бы они ни были. Ведение календаря отдела для проведения совещаний, доски объявлений, чаты для проведения дискуссии, - это другие возможности интранет. Критическим фактором успеха интранет является его способность обеспечить возможность поиска информации такую, которую не могут обеспечить внешние мощные поисковые машины. Для данной компании существуют уникальные команды, задачи, продукты и услуги. Команда, поддерживающая развитие интранет, должна использовать эти специфические артефакты, чтобы определить словари метаданных таким образом, чтобы поисковые машины компании могли помочь служащим найти информацию быстрее, чем какое-либо другое средство. Сопутствующее свойство – распределенная (общая) электронная закладка. В сочетании с маркировкой (разметкой), электронная закладка позволяет интранет пользователям создавать, управлять и разделять информацию. Например, одна из компаний решила проблему в деятельности своих торговых агентов, состоящую в том, что они проводят больше времени в офисах за поисками информации, которая им необходима для продажи продуктов, чем вне офиса со своими покупателями. Был создан Web портал для продаж. В сущности, значение портала заключалось в том, чтобы быть главным источником информации, за счет его связи с другими многочисленными источниками информации, некоторые внутри фирмы, некоторые снаружи, при этом не требовалось менять основообразующие системы. Данные, поступающие на портал, приходят из существующих Oracle и Siebel баз данных по продажам, комплектующим, ценам, наличному количеству, покупателям и пр. Портал также содержит новости, поступающие из внешней среды. 12. Стратегическое использование ИТ в смежных процессах (работа со смежниками). Рациональная организация процессов, пересекающих границы компании, - следующая большая задача информационного менеджмента. Компании тратят много времени и усилий на рационализацию своих внутренних процессов, но их эффективность обычно ограничивалась границами корпорации. Выигрывают те, которые изменяют свои процессы таким образом, чтобы скоординировать их с другими, так чтобы они образовывали цепочку работ, совершаемых разными организациями. Управление цепочкой поставок не является технической проблемой, как полагают некоторые, но проблемой управления и процессов. Работа со смежными бизнесами имеет многочисленные формы. Здесь будут рассмотрены следующие три. ▪ Координация со смежниками-поставщиками Совместная работа с предприятиями, не рассматриваемыми как конкуренты, является первым типом работы сквозь координации смежных бизнес-процессов. Например, два пищевых предприятия могут иметь одних и тех же покупателей (супермаркеты, розничная торговля), но не конкурировать друг с другом, можно назвать такие компании «субподрядчики». Например, фирма производит сыпучие продукты и доставляет их в супермаркеты. Это достаточно большой объем для того, чтобы содержать собственный парк транспортных средств. Однако, они имеют только небольшой процент бизнеса по товарам, требующим заморозки, объем которого недостаточен, чтобы наполнить рефрижератор для одного супермаркета. Таким образом, они используют одну грузовую машину для доставки в несколько супермаркетов, что не слишком эффективно из-за задержек, связанных с дорожным трафиком. Чтобы решить эту проблему фирма создала команду с другой фирмой, чтобы совместно осуществлять свои поставки на грузовиках другой фирмы. В результате получилось лучшее использование грузовиков и более высокая удовлетворенность супермаркетов (меньше задержек с поставками). Первая фирма перевозит свое масло на склады второй или для последующей доставки грузовиками фирмы, или для самовывоза покупателем. Фактически, координация оказалась выгодной, поэтому обе фирмы рассматривают возможность интеграции процессов оформления заказов и биллинга, снова, потому что они могут удвоить процессы там, где мог быть только один процесс. Чтобы наполнить свои грузовики еще больше, они создают совместную инициативу для клиентов, чтобы они делали заказ по обеим компаниям в одно время. То, что сдерживает совместную работу со-подрядчиков, это – недостаток удобных способов для легкого и быстрого использования совместной информации. Интернет убрал это ограничение. Совместное использование любых подобных ресурсов, таких как площадь склада в каком-то городе, или перевозка между какими то двумя городами, фактически, позволяет снизить стоимости. Компаниям, прежде чем начитать работать с со-подрядчиками, нужно делать собственные процессы эффективными, а затем совместно создавать новые объединенные процессы (которые для многих компаний являются новой территорией). Устранить дублирующие работы, фокусироваться на нуждах покупателя, и дать выполнить работу компании, находящейся в лучшей позиции. ▪ Установление близких и тесных отношений Стратегическое использование ИТ и Интернета в наиболее трудной области работы со смежными бизнесами компаний означает иметь отношения с различными игроками в одной экосистеме бизнеса – с инвестиционными банками, рекламными агентствами, специализированными провайдерами, поставщиками, дистрибьюторами, розничной торговлей и даже с конкурентами. Такие отношения часто сопровождаются объединением информационных систем. В отчете Gather EXP указывается, что компаниям необходимо определиться, какой уровень системной интеграции они хотели бы установить в каждом случае: свободных, близких или тесных. ◦ При свободной интеграции один участник обеспечивает другого ситуативным доступом к своей внутренней информации. Информация может быть, а может не быть конфиденциальной, и она доступна только когда это необходимо. Например, строитель малых энергоблоков позволяет поставщикам и покупателям выбирать спецификации на своем Web-сайте. Бизнес-процессы остаются отдельными. Такая ограниченная интеграция требует небольшого риска и затрат. ◦ В случае близкой интеграции два участника обмениваются информацией официально. Часть этой информации является, вероятно, конфиденциальной, и, хотя процессы участников различны, они все же выполняют некоторые задачи совместно. Например, они совместно управляют обменом. Примером являются авиалинии, совместно использующие данные о ценах друг друга, таким образом можно обеспечить эффективный сервис для покупателей, использующих несколько авиалиний в своих путешествиях. Этот уровень интеграции приводит к большим выгодам, так что существуют больше стимулов сделать отношения успешными. ▪ При тесных отношениях оба участника разделяют хотя бы один процесс, как партнеры, в той области бизнеса, которая наиболее важна для них. Обычно партнеры обмениваются большими объемами данных, данные могут быть сверх конфиденциальными, содержать ключевые события, такие как изменения цен. Примером могут быть отношения поставщика и розничного торговца, разделяющих обычный процесс инвентаризации. Целью является синхронизация операций, чтобы сократить затраты и скорость реакции. Тесная интеграция наиболее рискованна, потому что касается критических областей бизнеса и имеет высокие затраты. В некоторых случаях может быть трудно определить, где заканчиваются границы одной организации и начинаются с другой, потому что они перемешены. Следует особенно отметить, что из-за высокой стоимости и риска, компании могут иметь только несколько тесных отношений. Такие отношения возможны, когда выгоды перевешивают затраты и риски. Это подразумевает, что тесные отношения – это отношения, которые охватывают поистине критические процессы, где совместная работа с партнером значительно увеличивает добавочную стоимость. Оценить степень интеграции процессов можно по следующим параметрам. Число связей Потенциальная выгода Затраты на интеграцию Риски Тесные немного *** *** *** Близкие немало ** ** ** Свободные много * * * *- базовая согласованность, ** - средняя согласованность, *** - расширенная согласованность с значимыми деталями и непрерывной поддержкой ▪ Клиентоориентированная цепочка добавленной стоимости Цепочка добавленной стоимости компании состоит из вышестоящей цепи поставок (работа с поставщиками сырья и комплектующих) и нижестоящей цепочки требований (работа с дистрибуторами и розничной торговлей по продаже своих продуктов и услуг конечному покупателю). Традиционно большинство компаний работают на склад. Они делают автомобили или пакеты взаимных фондов, а затем «выталкивают» их покупателю. Это так называемый мир «выталкивающих поставок». Мы рассмотрим рост наоборот – мир «вытягивающих требований», в котором заказ покупателя запускает создание продукта или услуги, определенной покупателем. Цепь событий полностью изменена от выталкивания поставок к вытягиванию требований, от управления компанией до удовлетворения покупателей. Компания Dell – первый пример клиентоориенированной бизнес-модели вытягивания требований. Фактически, она стала моделью, которой многие компании восхищаются и подражают. Dell продает ПК, серверы, карманные компьютеры и другое электронное оборудование покупателям напрямую, физическим и юридическим лицам. Это крупнейший продавец ПК в мире, главным образом из-за цен, которые явились прямым результатом клиентоориентированной модели бизнеса. Когда покупатель покупает конфигурацию ПК он-лайн на Web-сайте Dell, информация по заказу поступает в производственный план Dell, по электронной почте посылается сообщение покупателю о дате доставки компьютера. Однако, Dell не делает большинство своих товаров, делают его поставщики. Около 30 из 200 поставщиков покрывают 80% бизнеса Dell. Это очень небольшое количество поставщиков, большинство производителей ПК имеют тысячу поставщиков. Dell создал экстранет для своих поставщиков так, чтобы они могли видеть информацию заказа и производственный план Dell. Фактически, они берут эту информацию и вводят ее в свои собственные производственные системы. В сущности, экстранет Dell постепенно становится собственной рыночной площадкой, где поступающие от покупателя заказы распределяются по поставщикам. Фактически, Dell постепенно переходит к производству информации, доступной поставщикам своих поставщиков - два ряда вниз. Их цель - прозрачность, дающая всей индустрии ясное представление о поставках и требованиях, так что они могут видеть, что продается и, возможно, за что покупатели платят, все при сохранении конфиденциальности. Так как поставщики могут просматривать всю цепочку требований и выяснять, какой из их компонентов был заказан и для какого типа компьютеров наиболее близко к реальному масштабу времени, они могут лучше прогнозировать. Результат – уменьшение запасов в цепи поставок. Сокращение запасов очень важно для бизнеса ПК, потому что 80% стоимости ПК приходится на компоненты. Цены быстро падают в отрасли, по крайней мере 1% каждые две недели не кажется чем-то необычным. Поэтому, чем меньше дней нужно держать в запасах, тем меньше денег связано с ними, и меньше денег они теряют. Dell изменил материальную цепочку добавленной стоимости, характерную для других производителей ПК. У них выталкивание поставок, у Dell – вытягивание требований. У Dell также есть финансовая цепочка добавленной стоимости. В модели выталкивания поставок производитель занимает деньги у банка, чтобы сделать запас. Затем они переплачивают банку по процентам, после того, как запас продан. В финансовой модели Dell вытягивания требований покупатель платит за свой ПК, когда он размещает свой заказ. Таким образом, Dell получает плату перед тем, как они произведут компьютер. Следовательно, они занимают меньше и платят меньше процентов, снижая стоимости и цены. 13. Понятие корпоративной информационной системы (КИС). Классы и уровни КИС. КИС можно определить как информационную систему, предназначенную для обеспечения эффективного функционирования компании путем автоматизированного выполнения функций управления. Это определение практически полностью совпадает с определением АСУ, использовавшихся в прошлом, и чье место занимает КИС в настоящее время. КИС объединяют стратегию управления предприятием и передовые информационные технологии. Наиболее развитые корпоративные ИС (КИС) предназначены для автоматизации практически всех функций управления корпорацией: от научно-технической и маркетинговой подготовки ее деятельности до реализации ее продукции и услуг. Для КИС характерен системный подход к комплексу задач управления предприятием и модульное построение программы, т.е. КИС является комплексом программ или программной системой, обеспечивающей основные бизнес- процессы в компании. КИС могут относиться к различным уровням, которые определяются масштабом охвата бизнес-процессов корпорации. На российском рынке представлены три уровня корпоративных систем (табл . 3.1). Таблица 3.1 – Уровни корпоративных информационных систем, представленных на российском рынке [9] Локальны е системы Малые интегрированн ые системы Средние интегрированные системы Крупные интегрированны е системы Предста - вители групп ·1С ·БЭСТ ·Инотек ·ИНФИН ·Инфософт ·Супер- Менеджер ·Турбо- Бухгалтер ·Инфо- Бухгалтер ·+ более 100 систем ·Concorde XAL ·Exact ·NS-2000 ·Platinum ·PRO/MIS ·Scala ·SunSystems ·БОСС- Корпорация ·Галактика/Парус ·Ресурс ·Эталон Axapta* ·JD Edwards (Robertson & Blums) ·MFG-Pro (QAD/BMS) ·SyteLine (СОКАП/SYMI X) ·SAP/R3 (SAP AG) ·Baan (Baan) ·BPCS (ITS/SSA) ·Oracle Applications (Oracl e) iRenaissance* Также корпоративные информационные системы делятся на два класса: финансово – управленческие и производственные. Финансово-управленческие системы включают подклассы локальных и малых интегрированных систем. Такие системы предназначены для ведения учета по одному или нескольким направлениям (бухгалтерия, сбыт, склады, учет кадров и т.д.). Системами этой группы может воспользоваться практически любое предприятие, которому необходимо управление финансовыми потоками и автоматизация учетных функций. Эти системы по многим критериям универсальны, хотя, нередко, разработчиками предлагаются решения отраслевых проблем, например, особые способы начисления налогов или управление персоналом с учетом специфики регионов. Универсальность приводит к тому, что цикл внедрения таких систем невелик, иногда можно воспользоваться "коробочным" вариантом, купив программу и самостоятельно установив ее на персональном компьютере. Производственные системы включают подклассы средних и крупных интегрированных систем. Эти системы, в первую очередь, предназначены для управления и планирования производственных процессов. Учетные функции, хотя и глубоко проработаны, выполняют вспомогательную роль и порой невозможно выделить модуль бухгалтерского учета, так как информация в бухгалтерию поступает автоматически из других модулей. Производственные системы значительно более сложны в установке (цикл внедрения может занимать от 6-9 месяцев до полутора лет и более). Это обусловлено тем, что система покрывает потребности всего производственного предприятия, что требует значительных совместных усилий сотрудников предприятия и поставщиков программного обеспечения. Производственные системы по многим параметрам значительно более жесткие, чем финансово-управленческие. Предприятие должно, в первую очередь, работать как хорошо отлаженные часы, где основными механизмами управления являются планирование и оптимальное управление производственным процессом, а не учет количества счетов- фактур за период. Эффект от внедрения производственных систем чувствуется на верхних эшелонах управления предприятием, когда видна вся взаимосвязанная картина работы, включающая планирование, закупки, производство, запасы, продажи, финансовые потоки и многие другие аспекты. При увеличении сложности и широты охвата функций предприятия системой, возрастают требования к технической инфраструктуре и компьютерной платформе. Таблица 3.2 – Характеристики корпоративных информационных систем [9] Малые ИС Средние ИС Крупные ИС Внедрение Поэтапное или «коро - бочный» вариант, 4 мес. Поэтапное, 6 – 9 мес. Поэтапное, сложное; 9 -12 мес. и более Функциональность Комплексный учет и управление финансами Комплексное решение: планирование, учет, управление,, производство То же Соотношение затрат лицензия /внедрение / оборудование 1 1 1 1 2 1 1, 1 – 5, 1 Стоимость 50 – 300 тыс. USD 200 – 500 тыс. USD 500 – 1000 тыс. USD и более 14. Корпоративные информационные системы класса MRP II – ERP Одной из разновидностей КИС являются решения класса ERP – это западный вариант развития корпоративных информационных систем. Страны рыночной экономики имеют большой опыт создания и развития информационных технологий для промышленных предприятий. Западные корпоративные информационные системы основаны на методах управления производством и дистрибуции, которые закреплены в таких стандартах как ERP (Enterprise Resources Planning), MRP (Material Requirements Planning), CRP (Capacity Resources Planning), MRPII (Manufacturing Resources Planning), и другие, отражающие некие концепции, которые могут применяться при создании той или иной КИС. То есть, ERP-система - это корпоративная информационная система, но КИС не обязательно является ERP-системой. Методы управления производством, которые лежат в основе данных концепций, закреплены в стандартах с соответствующими названиями, поддерживаемые американским обществом по контролю за производством и запасами, American Production and Inventory Control Society (APICS). MRP (Material Requirements Planning) - Методология планирования потребности в материальных ресурсах, по данным объемно-календарного плана производства. CRP (Capacity Requirements Planning) - Планирование производственных ресурсов. FRP (Finance Requirements Planning) - Планирование финансовых ресурсов. MRPII (Manufacturing Resources Planning) - Планирование производства. Интегрированная методология, включающая MRP/CRP и, как правило, MPS. При использовании данной методологии обязательно подразумевается анализ финансовых результатов производственного плана. ERP (Enterprise Resources Planning) - концепция бизнес-планирования. Под ERP подразумевается "интегрированная" система, выполняющая функции, предусмотренные концепциями MPS-MRP/CRP-FRP. Важным отличием от методологии MRPII является возможность "динамического анализа" и "динамического изменения плана" по всей цепочке планирования. Конкретные возможности методологии ERP существенно зависят от программной реализации. Концепция ERP более "размыта", чем MRPII. Если MRPII имеет явно выраженную направленность на производственные компании, то методология ERP оказывается применимой и в торговле, и в сфере услуг, и в финансовой сфере. Систему планов ERP-систем можно характеризовать тремя базовыми принципами: иерархичность, интерактивность, интегрированность. Иерархичность означает разделение планов по уровням иерархии: от топ- менеджмента, планирующего продажи и операции, до мастеров в цехах и на производственных участках, осуществляющих функции диспетчирования производственных наряд-заказов. Планы предприятия разрабатываются сверху вниз с одновременным обеспечением надежного механизма обратной связи. Интерактивность означает обеспечение возможности диалога с системой планирования, моделированием вероятных ситуаций, выбора оптимального решения. В MRP II эта возможность осуществляется на различных уровнях иерархии плановых решений. Интегрированность обеспечивается объединением всех основных функциональных модулей в пределах горизонта планирования. 15. Система планов MRPII Планирование начинается с стратегического бизнес-плана, который определяет цели деятельности компании, номенклатуру выпускаемой продукции, требуемые ресурсы, рынки сбыта и т.д., горизонт бизнес-планирования от двух до десяти лет. Этот план находится вне системы планирования MRP II, но создает базис для составления всех других планов системы. План продаж и операций (ранее называвшийся планом производства, APICS изменил термин на более адекватно отражающий характер плана) содержит, как правило, в стоимостном выражении, укрупненный план предприятия по товарно-номенклатурным группам. Этот план связан как с бизнес-планом, так и планом более низкого уровня – главным календарным планом производства (Master production schedule, MPS). Его назначение обеспечение предварительного баланса по объемам выпускаемой продукции, издержкам, ожидаемым доходам и расходам, он создает определенные ограничения/рамки, в которых более детально будут разрабатываться планы нижележащих уровней. Рисунок 3.1 – Представление системы планов верхнего уровня в MRP II Главный календарный план представляет собой календарный график производства продукции, в котором указаны сроки и объемы выпуска изделий. Основные его отличия от плана продаж и операций заключаются в том, что он составляется не по группам продукции, а по конкретным номенклатурным позициям, формируется не в стоимостном, а в натуральном выражении. Должно соблюдаться правило, что общие параметры главного календарного плана после объединения типоразмеров продукции в группы, предусмотренные планом продаж и операций, должны соответствовать последнему. Главный календарный план производства включает номенклатурные позиции независимого спроса. Данные о номенклатурных позициях независимого спроса представляют собой прогнозы сбыта и заказы на продажу, т.е. это такие номенклатурные позиции, потребность в которых не может быть вычислена на основании данных о потребности в других номенклатурных позициях. Ниже в табл.3.3 представлены уровни планирования и виды планов, реализуемых в системах MRP II. Представленные в таблице характеристики планов встречаются наиболее часто, но могут отличаться для различных областей использования. Таблица 3.3 – Иерархия планов MRP II [5] Уровень планирования Объект Горизонт Интервал Оценка выполнения План продаж и операций (Sales&Operations Plan) Товарно- номенклатурная группа (Product line) 1-2 года Квартал или месяц Ежеквартально Главный календарный план производства (Master Production Schedule) Изделия независимого спроса и график финальной сборки (Independent Demand items and Final Assembly Квартал – год Месяц или неделя Ежемесячно Schedule) План Изделия 1-6 месяцев Неделя или Еженедельно потребности в зависимого день материалах спроса (Material (Dependent Requirements Demand items) Planning) Оперативное Технологические 1-4 недели День или час Ежедневно управление операции производством (Operations) (Production Activity Control or Shop Floor Control) План потребности в материалах разрабатывается для изделий зависимого спроса, потребность в которых может быть вычислена на основании данных о потребности в других номенклатурных позициях. По сути, планирование потребности в материалах представляет собой расчет прогнозируемого дефицита компонентов и материалов и формирование предложений по устранению этого дефицита. Оперативное управление производством ответственно за формирование графиков выполнения производственных заказов (заданий) в разрезе технологических операций и представляет собой наиболее детализированный план. 16. Укрупненное планирование. Планирование продаж и операций. Планирование продаж и операций (иногда называемое укрупненным планированием) представляет собой процесс принятия решения по выработке среднесрочного плана по всем областям деятельности предприятия в соответствии с направлениями, задаваемыми бизнес-планом. Руководство, отвечающее за среднесрочный уровень выполнения планов, по результатам регулярно проводимых совещаний и рассмотрения различных прогнозов спроса, поставок и финансовых результатов предприятия, формирует и утверждает единый план деятельности, увязывающий основные ресурсы предприятия: время, финансы, персонал, производственные мощности. План продаж и операций разрабатывается руководством предприятия с привлечением всех функциональных руководителей высшего уровня управления компанией. Важно отметить значение руководства предприятия в принятии решений по выбору данного плана, обеспечению условий для его выполнения и ответственности за полученные результаты. Компьютерные программы корпоративной информационной системы могут обеспечить руководство только информацией и прогнозными расчетами. Характеристики плана продаж и операций: 1. горизонт планирования от трех до восемнадцати месяцев, с периодическим пересмотром; 2. номенклатура производимых продуктов рассматривается укрупнено; 3. ресурсы предприятия также рассчитываются укрупнено; 4. уравновешивается спрос и предложение, за счет регулирования производительности, занятости труда и оборудования, запасов и пр., в заданных ресурсных ограничениях. Двумя основными результатами плана продаж и операций являются план продаж (сбыта) и план производства (производственный план). Утвержденный план продаж и операций является регулятором для всех остальных календарных планов. По существу, этот план представляет собой бюджет, устанавливаемый руководством предприятия, для разработки главного календарного плана, и всех последующих календарных планов (план потребности в материалах, MRP; план потребности в мощностях, CRP; и др.). Элементами планирования данного уровня являются продуктовые группы (продуктовые линии, товарно-номенклатурные группы), а не конкретные модели продуктов, т.к. это способствует: ◦ уменьшению сложности контроля руководством сотен номенклатурных позиций; ◦ упрощению итогового контроля успешности бизнеса, его соответствия бизнес- плану, поскольку продуктовые группы представлены не в натуральном, а в стоимостном выражении. План продаж и операций использует принцип скользящего планирования, т.е. при окончании очередного планового периода, горизонт планирования продлевается на один период вперед, при необходимости производятся корректировка плана на все последующие периоды. 17. Разработка главного календарного плана производства (Master Production Schedule – MPS) MPS – это календарный план (график) выпуска продукции, с указанием сроков, объемов выпускаемых номенклатурных позиций. В план включаются как номенклатурные позиции независимого спроса, так и сборочные единицы, входящие в состав готовой продукции, которое предприятие планирует выпускать самостоятельно. Главный календарный план производства утверждается и запускается в исполнение руководством. Этот план является основой (предоставляет входную информацию) для составления планов нижнего уровня - потребности в материальных ресурсах и потребности в производственных мощностях, что налагает жесткие требования к его точности и адекватности. Поскольку при разработке главного календарного плана используется принцип скользящего планирования, то степень его точности изменяется в пределах горизонта планирования. Как только завершен очередной интервал плана, в MPS добавляется еще один интервал, и горизонт планирования всегда остается постоянным, его продолжительность должна зависеть, по мнению большинства специалистов, от длительностей цикла закупки и производственного цикла по самой медленно производимой номенклатурной позиции. На ближайшие интервалы план обеспечен достоверной информацией, поскольку оперируют с фактическими данными, для отдаленных интервалов планирования используются прогнозы, поэтому точность планирования на этих интервалах значительно ниже. В MPS используются два вида прогнозов – прогнозы, основанные на статистическом анализе ретроспективных данных, и прогнозы, построенные на предположениях и оценках специалистов. В результате прогноз спроса базируется на следующих составляющих: • прогноз, генерируемый системой планирования (программно); • прогноз, вводимый вручную; • календарный график, имеющихся заказов покупателей; • комбинирование этих трех составляющих в текущую оценку спроса. Таблица 3.4 – Главный календарный план для производства изделия ХХХ Номер недели 1 2 3 4 5 6 7 8 9 10 11 12 13 Прогноз системы (стр. 1) 60 60 60 60 60 60 60 60 60 60 60 60 60 Прогноз ЛПР (стр. 2) 50 60 40 50 70 80 80 70 70 Имеющиеся заказы на продажу (стр. 3) 55 60 30 20 25 5 10 Итого спрос (стр. 4) 55 60 40 50 70 80 80 70 70 60 60 60 60 Подтвержденные производственные заказы (стр. 5) 80 80 80 80 80 60 60 60 60 60 Нетто-потребность (стр. 6) Начальный запас (стр. 7) 60 Прогнозируемый запас (стр. 8) 85 105 145 175 185 165 145 135 125 125 65 5 -55 Объем продукции, которую можно обещать отгрузить, нарастающим итогом (стр. 9) 85 105 155 215 270 325 385 435 495 555 555 555 555 Реквизиты главного календарного плана производства можно свести в табличную форму, например табл. 3.4. Формат таблицы может быть разным для разных предприятий, продуктов, производственных процессов. Прогноз системы – это прогноз спроса, выдаваемый программным модулем системы, используется математико-статистический подход. Прогноз ЛПР – прогноз лица принимающего решение, экспертная оценка, вводится вручную. Имеющиеся заказы на продажу – это заказы покупателей на номенклатурную позицию, подтвержденные покупателем, имеющие конкретную дату поставки. Итого спрос – утвержденный спрос, представляющий комбинацию первых трех строк, экспертной оценке дается предпочтение. Подтвержденные производственные заказы – это наряд заказы, которые уже утверждены к исполнению, любые изменения этого параметра могут производиться только ЛПР. Начальный запас – имеющийся запас продукции на начало периода. Прогнозируемый запас – прогнозируемый складской остаток на конец текущего интервала планирования. Рассчитывается следующим образом: стр.8 (i) = стр.8 (i - 1) + (стр.5 (i) - стр.4 (i) + стр.7 (i)); где i – номер интервала планирования. Объем продукции, которую можно обещать отгрузить, нарастающим итогом – доступное количество продукции, которую можно отгружать по вновь поступившим заказам; рассчитывается следующим образом: стр.9 (i) = стр.9 (i - 1) + (стр.5 (i) - стр.3 (i)); где i – номер интервала планирования. Проверка адекватности разработанного главного календарного плана осуществляется с помощью специального программного модуля укрупненной оценки потребности в мощностях (rough cut capacity planning - RCCP). С помощью этого модуля осуществляется быстрая проверка реалистичности обеспечения производства несколькими ключевым ресурсам. Для этого в RCCP каждая номенклатурная позиция сопоставляется со списком/спецификацией ключевых ресурсов, требуемых для изготовления единицы продукта. Если выявлено несоответствие между параметрами плана и возможностями его ресурсного обеспечения, то проблема решается, либо за счет изменения плана, либо за счет приобретения дополнительных ресурсов. Для разработки главного календарного плана необходима информация с верхнего уровня планирования: количественные данные в форме долгосрочного плана производства, описывающего объемы и сроки производства по товарно-номенклатурным группам; качественные данные, характеризующие политику предприятия в области уровня запасов, использования сверхурочных работ, субподряде и т.п. Обратная связь с вышестоящими уровнями планирования возникает тогда, когда при разработке главного календарного плана производства возникает ситуация, которую нельзя разрешить в рамках установленных ограничений. Главный календарный план формирует показатели, по которым осуществляется координация производства на нижестоящем по иерархии уровне - оперативном управлении производством. Осуществляя обратную связь, уровень оперативного управления предоставляет данные краткосрочного характера в главный календарный план: • фактические результаты выполнения плана; • данные о конфликтных ситуациях, которые неразрешимы на оперативном уровне. 18. Метод планирования материальных ресурсов (MRP – Material Resource Planning) В отличие от методов теории управления запасами, предполагающих независимый спрос на всю номенклатуру, MRP часто называют методом расчетов для номенклатуры «зависимого спроса» (то есть формирования заказов на узлы и комплектующие изделия в зависимости от заказа на готовую продукцию). Алгоритм MRP не только выдает заказы на пополнение запасов, но и позволяет корректировать производственные задания с учетом изменяющейся потребности в готовых изделиях. Введем основные понятия MRP: • Материалы - все сырье и отдельные комплектующие, составляющие конечный продукт. • MRP-система, MRP-программа - компьютерная программа, работающая по алгоритму, регламентированному MRP методологией. Как и любая компьютерная программа, обрабатывает файлы данных (входные элементы) и формирует на их основе файлы - результаты. • Статус материала является основным указателем на текущее состояние материала. Каждый отдельный материал, в каждый момент времени, имеет статус в рамках MRP-системы, который определяет, имеется ли данный материал в наличии на складе, зарезервирован ли он для других целей, присутствует ли в текущих заказах, или заказ на него только планируется. Таким образом, статус материала однозначно описывает степень готовности каждого материала быть пущенным в производственный процесс. • Страховой запас материала необходим для поддержания процесса производства в случае возникновения непредвиденных и неустранимых задержек в его поставках. По сути, в идеальном случае, если механизм поставок полагать безупречным, MRP-методология не постулирует обязательное наличие страхового запаса, и его объемы устанавливаются различными для каждого конкретного случая, в зависимости от сложившейся ситуации с поступлением материалов. • Потребность в материале в компьютерной MRP-программе представляет собой определенную количественную единицу, отображающую необходимость в заказе данного материала. Различают понятия - полной потребности в материале (брутто-потребность), отображающей количество материла, необходимое для выполнения плана производства, и - чистой потребности (нетто-потребность), при вычислении которой из полной потребности вычитается наличие всех страховых и зарезервированных запасов данного материала. Например, для изделия А существует производственный план в размере 100 единиц. Исходя из этого, требуемое количество компонент (полная потребность, брутто потребность) составит: В - 100; С - 200; D - 200; E - 400; F - 200 единиц. Расчет чистой потребности (нетто потребности) приведен в табл. 3.5. Таблица 3.5 – Расчет чистой потребности в материалах по известной полной потребности и данных о наличии на складе A B C D E F Брутто потребность 100 100 200 200 400 200 В наличии 100 80 120 280 220 Нетто потребность 100 120 80 120 Заказ в системе автоматически создается по возникновению отличной от нуля чистой потребности. На практике MRP-система представляет собой компьютерную программу, рис.3.2. Рисунок 3.2 - Входные элементы и результаты работы MRP-программы Входными данными для программы являются: Описание состояния материалов - основной входной элемент, указывающий статус каждого материала: данные о запасах продукции, сборочных единицах и материалах, а также информация об открытых (запущенных) заказах. Учитываются запасы всех промежуточных стадий производства продукции (полуфабрикаты собственного изготовления, сборочные единицы, узлы и т.п.). Понятие «открытый заказ» введено как для производимых, так и для закупаемых номенклатурных позиций и относится к тем заказам, изготовление или закупка которых начаты, но ещё не завершены. Программа производства (master planning scheduling, MPS), или объемно- календарный план представляет собой оптимизированный график производства партий готовой продукции на определенный период, например, готовые изделия, запасные части, продаваемые на сторону полуфабрикаты и комплектующие и т.п. Потребность может быть представлена или прогнозом продаж, или уже имеющимися в наличии заказами покупателей, или тем и другим одновременно. Пример объемно-календарного плана приведен в табл.3.6. Таблица 3.6 – Пример MPS-планирования Период MPS изделие 1 2 3 4 5 6 7 8 Изделие 1 86 93 119 100 100 100 100 100 Изделие 2 50 50 50 50 Изделие 3 75 120 47 20 17 10 Изделие 4 125 125 125 125 125 125 125 125 Перечень составляющих конечного продукта (Bills of Material, BOM), на русский язык этот термин приблизительно можно перевести как “состав изделия”, “рецептура”, “сборочная спецификация”. Этот термин означает список материалов и их количество, требуемое для производства единицы конечного продукта. BOM точно определяет состав компонентов и материалов (входящих в готовое изделие в 100% случаев), жёстко определённые нормы их расхода на одну единицу готовой продукции. BOM можно свести в таблицу. Например, табл. 3.7. Таблица 3.7- Список материалов (BOM – BILL of Material) для готовой продукции 000 Уровень в BOM Код позиции Описание Количество на единицу родительского изделия Единица измерения 000 Готовая продукция 1 1 001 Сборочная единица 1 2 011 Компонент 2 3 111 Материал 5 2 012 Компонент 3 1 002 Сборочная единица 2 2 021 Компонент 2 3 211 Материал 4 3 212 Материал 10 2 022 Компонент 4 MRP формирует два массива сообщений: плановые заказы (planned orders) и рекомендации (action messages). Плановые заказы предлагают размер заказа, дату запуска и дату выполнения заказа как результат работы MRP в том случае, когда MRP встречается с наличием чистой (нетто) потребности. Плановые заказы, создаются компьютерной системой, существуют только в компьютерной системе и могут быть изменены или удалены компьютерной системой при последующем запуске MRP при изменении исходных данных. Рекомендации – это результат работы системы, определяющий тип действий, необходимых для устранения текущих или потенциальных проблем. Примерами рекомендаций в системе MRP могут служить «запустить заказ», «перепланировать заказ», «отменить заказ». Рекомендации придают MRP характер системы поддержки принятия решений, хотя и в весьма ограниченном объёме, ибо MRP не предлагает полномасштабных сценариев развития событий при тех или иных вариантах решений. [5] 19. Планирование потребностей в производственных мощностях (CRP-Capacity Requirements Planning) Схема планирования потребности в мощности (Capacity requirements planning) представлена на рис. 3.3. Рисунок 3.3 - Планирование потребности в мощностях Для работы механизма CRP необходимы следующие массивы исходных данных. 3. Данные о главном календарном плане производства (MPS). 4. Результаты работы MRP-программы в виде плановых заказов на сырье, материалы, комплектующие, поэтому запуск CRP возможен только после того, как отработала программа MRP. 5. Данные о рабочих центрах. Рабочий центр  это определённая производственная мощность, состоящая из одной или нескольких машин (людей и/или оборудования), которая в технологии CRP может рассматриваться как одна производственная единица. Иначе, рабочий центр – это группа взаимозаменяемого оборудования, расположенная на локальном производственном участке. Для работы CRP необходимо предварительное формирование рабочего календаря рабочих центров с целью вычисления доступной производственной мощности. 6. Данные о технологических маршрутах изготовления номенклатурных позиций. Здесь указываются все сведения о порядке осуществления технологических операций и их характеристиках (технологические времена, персонал, другая информация). Этот массив данных вместе с первым массивом (MPS) формирует загрузку рабочих центров. CRP информирует обо всех расхождениях между планируемой загрузкой и имеющимися мощностями, позволяя предпринять необходимые регулирующие воздействия. При этом каждому изготавливаемому изделию назначается соответствующий технологический маршрут с описанием ресурсов, требуемых на каждой его операции, на каждом рабочем центре. Следует отметить, что CRP не занимается оптимизацией загрузки, осуществляя лишь расчётные функции по заранее определённой производственной программе согласно описанной нормативной информации. В этом смысле и MRP, и CRP – плановые механизмы, позволяющие получать корректный и реальный план-график производства на основе использования опыта и знаний лиц, принимающих решения. Обе эти системы можно с некоторой долей условности отнести к системам поддержки принятия решений, так как они позволяют просчитывать последствия, хотя и не выдают никаких практических вариантов преодоления возникающих проблем. Если в результате работы CRP-модуля установлено, что MRP-план неосуществим, то производственная программа (MPS) должна быть пересмотрена, более того, вероятно, необходимо пересмотреть весь план деятельности. 20. Управление запасами в MRP II Основной задачей управления запасами является инвестирование средств в запасы таким образом, чтобы достигать стратегических целей бизнеса. Запасы часто используются как критерий суждения об эффективности планирования, производства и управления в целом в компании. Основной объект управления запасами – формирование «буфера» для нейтрализации колебаний в поставках и спросе. Системы управления запасами Системы управления запасами номенклатурных позиций могут быть разделены на две основные категории. Классифицирующим признаком выступает использование того или иного механизма обновления данных об имеющихся запасах. Первым типом систем управления запасами являются системы с периодическим обновлением данных о запасе. При их применении производится периодический подсчет фактических запасов (обычно в конце планового периода); данные о движении запасов (приходование, отпуск и др.) не фиксируются в системе. Эта система проста в эксплуатации, но обладает существенным недостатком – в случае расхождения между данными о запасах в базе данных и фактическим данными, выявленными, например, в ходе инвентаризации, не удается проследить причины возникновения этого расхождения и, следовательно, принять меры, предупреждающие возникновение таких ситуаций. Второй тип - системы с непрерывным обновлением данных, в которой операции с запасами фиксируются по их возникновении. Система позволяет проследить пути движения запасов и адекватно реализовать партионный контроль, т.е. проследить пути движения партий номенклатурных позиций по их идентификационным номерам. Данная система позволяет динамически поддерживать механизм резервирования запасов под производственные заказы и заказы на продажу. Однако для работы такой системы требуется создать надлежащую организацию учета и движения запасов. АВС-анализ Суть метода заключается в том, что все номенклатурные позиции классифицируются по признаку относительной важности и для каждой выделенной категории формируются свои методики управления запасами. Обычно прибегают к трехступенчатому ранжированию номенклатурных позиций: на классы А, В и С. В MRP-системах, как правило, существует возможность задать номенклатурной позиции определенный класс как вручную, так и в соответствии с рекомендациями системы относительно присвоения класса. В последнем случае тип класса определяется главным образом по признаку годового использования номенклатурной позиции в стоимостном выражении, при этом используются накопленные в системе статистические данные. После присвоения каждой номенклатурной позиции определенного класса к каждому из классов применяются свои правила контроля запасов. Для номенклатурных позиций класса А рекомендуются следующие правила. 3. Частая оценка прогноза и метода прогнозирования, поскольку любой прогноз несет некоторую ошибку, то чем дороже и дефицитнее позиция, тем дороже обходится ошибка. 4. Частый, например ежемесячный, циклический подсчет запасов с жесткими допусками, недопустимо сколько-нибудь существенное отклонение фактических данных о запасах с данными, имеющимися в информационной системе. Каждое такое отклонение должно расследоваться на предмет выяснения его причин. 5. Ежедневное обновление данных в базе данных. 6. Частое рассмотрение требований спроса, размеров партий, страхового запаса, позволяющее тщательно отслеживать все параметры планирования, выявлять реальные потребности в номенклатурных позициях. 7. Тщательное отслеживание длительности цикла поставок, чем короче цикл, тем ниже потребность в оборотных средствах, для дорогих позиций это окупается сторицей. Для номенклатурных позиций класса В применяются те же меры, что и для позиций класса А, но реже и с большими приемлемыми допусками. Для номенклатурных позиций класса С сформулированы следующие правила. 5 Изделие должно быть в наличии, т.е. запасов изделий класса С может быть больше, чем нужно, но не должно быть меньше, чем необходимо. 6 Простая фиксация данных или вообще отсутствие фиксации данных в базе данных; возможно использование для контроля объема запасов процедуры периодического осмотра (обзора). Может применяться система с периодическим обновлением данных в системе либо данные номенклатурные позиции выводятся за границы MRP-системы вообще. 7 Большие размеры партий (заказов) и большой страховой запас. Крупные партии не влекут за собой существенных затрат, связанных с хранением запасов номенклатурных позиций класса С, поэтому имеет смысл экономить пре- имущественно на подготовительных издержках, заказывая помногу. 8 Хранение на территориях, немедленно доступных для персонала, использующего эти номенклатурные позиции в производственном процессе. Это упрощает процедуру отпуска запасов в производство и устраняет лишнюю бюрократическую бумажную работу, также влекущую за собой определенные затраты. 9 Нечастый (редкий) подсчет запасов (раз в год или в полгода) с большими приемлемыми допусками (вплоть до, например, взвешивания вместо подсчета). Рассмотрим простой пример проведения АВС-классификации номенклатурных позиций по критерию объема потребления в стоимостном выражении. Пусть имеется десять номенклатурных позиций, известен объем их потребления в натуральном и стоимостном выражении за некоторый плановый период (скажем, год). Сводка по этим номенклатурным позициям приведена в таблице на рис. 16. Рисунок 3.4 – Исходные данные для проведения АВС-анализа Проводится ранжирование номенклатурных позиций по принятым критериям (в примере — по объему использования в стоимостном выражении), которое приведено на рис. 17, после чего номенклатурным позициям в соответствии с заданным распределением присваиваются классы относительной важности, что для рассматриваемого примера также отражено на рис. 17. Рисунок 3.5 – АВС-классификация номенклатурных позиций Для различных классов номенклатурных позиций могут устанавливаться различные допуски отклонения данных от фактически имеющегося запаса. Точность данных о запасах может оцениваться как в натуральном, так и в стоимостном выражении. Можно выделить два метода контроля точности данных о запасах: 9.2 Полная инвентаризация, проводимая по полному перечню номенклатурных позиций, обычно с приостановкой складских операций и производства, раз в год или раз в полгода. Она может требовать для проведения нескольких дней при участии многих людей из разных отделов и служб, не всегда хорошо знакомых с предметной областью, причем по отдельным позициям может потребоваться пересчет (в случае больших отклонений). По окончании производится полная сверка данных и проведение в информационной системе необходимых корректирующих операций. 9.3 Текущая инвентаризация, или циклический подсчет, — производится по ограниченному перечню номенклатурных позиций, обычно без приостановки складских операций, с заданной периодичностью, разной для разных номенклатурных позиций. Этот метод дополняет, а иногда и заменяет полную инвентаризацию, производится хорошо подготовленным персоналом, иногда на этом и специализирующимся, и позволяет выявить причины неточности данных о запасах, тогда как полная инвентаризация в силу нечастого ее проведения такой задачи решить не позволяет. MRP-системы обычно содержат механизмы, помогающие проведению такого рода контрольных проверок, однако все же ведущую роль в этом играет персонал предприятия. 21. Управление закупками в MRP II Прежде всего следует дать определение снабжения (закупок), которое сформулировано APICS: «Снабжение (Purchasing) — это термин, используемый в промышленности и управлении для обозначения функции и ответственности за заказ основных и вспомогательных материалов (materials), расходных материалов (supplies) и услуг (services)». Место снабжения в системе MRP II иллюстрируется рис. 3.6. Рисунок 3.6 – Место снабжения в системе MRPII Классификация приобретаемых объектов Все приобретаемые при помощи отдела снабжения объекты можно разделить на три основные группы, каждая из которых имеет свои особенности: • Оборудование и специальные услуги. При приобретении этих объектов отдел снабжения играет вспомогательную роль, данные закупки не носят оперативного характера и относятся преимущественно к сфере инвестиционного планирования. MRP- система учитывает основные фонды в качестве ограничений при планировании ресурсной обеспеченности производства (на уровнях планирования потребности в ресурсах (RRP), укрупненного планирования потребности в мощностях (RCCP) и планирования потребности в мощностях (CRP)). • Стандартные офисные и вспомогательные производственные поставки и услуги. В основном это номенклатурные позиции класса С, легкодоступные по первому запросу (бумага, недорогой типовой крепеж и т. п.). Подобные поставки обычно планируются не через механизм MRP, а более простыми методами (например, с использованием статистической точки заказа или при помощи методов визуального контроля уровня запасов). • Основные материалы, комплектующие изделия и прочие поставки, используемые для производства основной продукции. Эта группа объектов является основной заботой отдела снабжения. Определение размеров и сроков выполнения заказов на закупку этих номенклатурных позиций должно быть тесно увязано с планом производства, который, в свою очередь, формируется на основе плана сбыта продукции, т. е. заказы на их закупку «наследуются» от плановой системы. Также отметим, что затраты на их закупку составляют большую долю текущих затрат, поэтому данным номенклатурным позициям посвящена большая часть рабочего времени сотрудников отдела снабжения, ибо эти изделия являются основной зоной ответственности снабженцев. С позиций MRP-системы объекты данной группы, особенно относящиеся к классам А и, возможно, В, должны планироваться с применением механизма календарной точки заказа (т. е. MRP). Жизненный цикл заказа на закупку Заказ на закупку либо может быть сформирован на основании непосредственной заявки на закупку (созданной вручную или предложенной MRP-системой и впоследствии подтвержденной человеком), либо предварительно заключен долгосрочный контракт, а уже на основании контракта и сформированной заявки, может быть создан заказ на закупку. В любом случае необходимо подтверждение заявки ответственным лицом, без этого заказ на закупку создан быть не может, т.е. плановый механизм MRP построен таким образом, что система создает заявки на закупку, которые становятся реальными заказами, только после подтверждения специалистом. Такая схема может быть объяснена следующими причинами: • Компьютер не может быть ответственным за принятое решение. Причем, в зависимости от суммы заказа решение о его одобрении может приниматься разными по степени ответственности должностными лицами. • Поскольку MRP формирует отдельную заявку на каждую номенклатурную позицию, специалист может сократить издержки снабжения за счет • объединения нескольких заявок, поступивших с разных участков компании на одну и ту же номенклатурную позицию; • консолидации заявок на различные номенклатурные позиции, закупаемые у одного и того же поставщика; • рассмотрения целесообразности консолидации заявок с разными датами поставок. В этом случае для принятия решения следует взвесить величину потенциальной экономии и те дополнительные издержки, которые понесет предприятие при более раннем, чем это необходимо, заказе изделий Далее заказ, будучи подтвержденным, размещается у поставщика. При получении номенклатурной позиции по данному заказу MRP-система проверяет, осталось ли еще какое-то количество номенклатурной позиции, не поставленной поданному заказу, и если нет, автоматически закрывает заказ. В любом случае в системе существует возможность принудительного закрытия заказа, даже в случае неполного получения зафиксированного в нем количества. 22. Оперативное управление исполнением плана производства (Production Activity Control or Shop Floor Control - SFC) Согласно стандарту: «Оперативное управление исполнением плана производства – это система для использования данных из цеха для ведения и сообщения данных о состоянии производственных заказов и рабочих центров. Основными функциями оперативного управления исполнением плана производства являются: • Назначение приоритета каждому производственному заказу. • Ведение данных об объеме незавершенного производства. • «Доставка» информации о состоянии производственных заказов в офис. • Обеспечение фактическими результатными (выходными) данными для целей управления производственными мощностями. • Обеспечение данными о количестве изделий по местам хранения и производственным заказам в целях учета запасов незавершенного производства в бухгалтерском учете. • Обеспечение критериев оценки эффективности работы, использования рабочего времени и производительности рабочих и оборудования. Для отслеживания перемещения материалов в цехе оперативное управление исполнением плана производства может использовать контроль заказов или контроль материального потока». Отчет по контролю заказов позволяет получать информацию о степени готовности каждого заказа, что в т.ч. создает возможность для любого клиента отслеживать состояние его заказа. Отчет по контролю входных /выходных материальных потоков предоставляет данные, важные для оценки загрузки рабочих центров. Обобщенный алгоритм SFC представлен на рис. 3.7. Управление заказами основано на отслеживании их состояний. Заказ, проходя все стадии производственного процесса, переходит из одного состояния в другое при выполнении некоторых действий над ним. Количество возможных состояний, отслеживаемых системой, может различаться в разных конкретных реализациях систем MRP II. Выделим несколько узловых состояний, являющихся наиболее важными, а иногда и обязательными. 1. Плановый заказ – заказ, сформированный MRP-системой, существует только внутри нее, он свидетельствует о наличии дефицита номенклатурных позиций, либо прогнозе дефицита. Этот заказ может быть отменен или изменен, но только MRP- модулем, или подтвержден, но только работником. Рисунок 3.7 – Алгоритм оперативного управления исполнением плана производства[5] 2. Подтвержденный заказ может быть введен вручную, либо получен из планового заказа. По этому заказу система может выдавать только рекомендации, никаких действий над ним она производить не может. 3. Развернутый заказ – заказ, к которому прикрепляется MRP-системой информация о спецификации продукта и технологическом маршруте его изготовления. 4. Зарезервированный заказ – заказ, под который согласно спецификации продукта, на складе зарезервированы материалы-компоненты. 5. Запущенный заказ – заказ, запущенный в производство, для него напечатан весь комплект документов. 6. Закрытый заказ – прекращено выполнение заказа, либо потому что он полностью выполнен, либо по нему принято такое волевое решение. Контролируется также статус каждой операции технологического маршрута продукта. Минимально необходимый перечень статусов операций: ◦ Заказ находится в очереди на операцию; ◦ Операция выполняется; ◦ Операция выполнена и закрыта. На рис. 3.8 представлен алгоритм запуска производственных заказов, показывающий, как производственный процесс меняет состояние заказа. Рисунок 3.8 – Алгоритм запуска производственных заказов[5] Основными функциями запуска заказов и диспетчирования являются: 1. Управление приоритетами заказов. Эта функция позволяет гибко следовать политическим целям организации. Примерами устанавливаемых приоритетов являются: ◦ обработка заказов осуществляется в порядке их прибытия на рабочий центр; ◦ обработка заказов осуществляется в порядке обратном их времени обработки; ◦ в первую очередь запускаются заказы с более ранней требуемой датой выполнения; ◦ сначала запускаются заказы с наименьшим количеством оставшихся операций; ◦ другие. 2. Управление очередями заказов. Очередь к рабочему центру измеряется в часах его работы, необходимых для того, чтобы обработать все заказы, стоящие в очереди. Спланировать работу без очередей практически невозможно, поэтому на практике эта функция сводится к оптимальному использованию наиболее критических рабочих центров. 3. Планирование и контроль входных и выходных потоков на рабочих центрах. Функция отслеживает параметры плановых входного и выходного потоков (рассчитанных CRP и утвержденных руководством): с фактическими значениями, с корректировкой, выходящих из-под контроля ситуаций. 4. Формирование и направление последовательности заказов. 5. Назначение выполнения заказов рабочим центрам. Функции 4 и 5 выполняются на основании решений, принятых по функциям 1, 2, 3. Отчеты, создаваемые на оперативном уровне управления производством, предназначены, во-первых, для информирования руководства о состояниях заказов, а во- вторых, набор отчетов для оценки текущей деятельности. Отчеты первого вида, как правило, содержат информацию о текущем местонахождении и состоянии заказа, фактически потраченных на каждой операции ресурсах и пр. Отчеты второго вида представляют собой аналитические срезы информации для различных категорий работников. Как правило, конкретная реализация MRP-системы имеет свой стандартный набор отчетов, который при внедрении системы адаптируется под требования организации. 23. Концепция ERP (Enterprise Resources Planning – Планирование ресурсов предприятия) К MRP II-системе постепенно добавлялись возможности по учету и управлению другими затратами предприятия, расширяя ее и формируя новую концепцию, получившую название ERP (планирование ресурсов предприятия). Для ERP иногда применяют термин Enterprise-wide Resource Planning (планированием ресурсов в масштабе предприятия), и действительно ERP охватывают всю финансово- хозяйственную и производственную деятельность. В основе методологии ERP лежит принцип единого хранилища данных, содержащего всю деловую информацию, накопленную организацией в процессе ведения бизнеса, включая финансовую информацию, данные, связанные с производством, управлением персоналом, или любые другие сведения. Это устраняет необходимость в передаче данных от одной информационной системы к другой и создает дополнительные возможности для анализа, моделирования и планирования, любая часть информации, которой располагает данная организация, становится одновременно доступной для всех работников, обладающих соответствующими полномочиями. ERP-методология до настоящего времени должным образом не систематизирована, и рассматривается как надстройка над MRPII, нацеленная на оптимизацию работы с удаленными объектами управления. ERP-системы должны удовлетворять требованиям: • обеспечения режима работы близком к реальному времени; • сохранения общей модели управления для предприятий любых отраслей; • поддержки территориально распределенных структур; • работы в широком спектре аппаратно-программных платформ и СУБД. Как правило, ERP-системы строятся по модульному принципу, в той или иной степени охватывая все ключевые процессы деятельности компании. Системы MRP II / ERP не могут заменить все приложения, эксплуатируемые на предприятии, модули этих систем практически всегда используются совместно с другими системами, функциональность которых не охватывается ERP-системами, например системы проектирования, конструкторской и технологической подготовки производства, геоинформационные системы и др. Это требуют интеграции модулей MRP II / ERP с существующим на предприятии программным обеспечением. Начиная с середины 90-х годов, концепция ERP стала очень популярной в производственном секторе, поскольку ее использование для планирования ресурсов позволило существенно сократить время выпуска продукции, снизить уровень товарно- материальных запасов, а также улучшить обратную связь с потребителем при одновременном сокращении административного аппарата. Методология ERP, позволяя объединять информацию обо всех ресурсах предприятия, добавила, таким образом, к MRP II возможности управления заказами, поставками, финансами и т.д. ERP-система не является простым расширением системы MRPII. MRPII была построена и развивалась как замкнутая система, обслуживающая сугубо внутренние потребности предприятия. ERP имеет выходы во внешнюю среду и предназначена для решения задач комплексного управления предприятием. ERP системы, как дальнейшее развитие интегрированных информационных систем управления предприятием, как правило, включают: 1) модуль финансового планирования FRP (Finance Requirements Planning) 2) модуль планирования ресурсов распределения и ресурсов для проведения технологического обслуживания и выполнения ремонтов (DRP – I, DRP – II) Рассмотрим возможности системы MRP II в поддержке функции финансового планирования: • данные о заказах на закупки, сроках их исполнения и условиях платежей позволяют рассчитывать выплаты денежных средств по всем поставщикам, сколько, когда и кому. • данные о загрузке мощностей и использовании рабочего труда позволяют определить обязательства предприятия по расчету с персоналом. • данные о поставках готовой продукции позволяют рассчитать график финансовых поступлений. Возможности финансового планирования и анализа в MRP II ограничены из-за отсутствия информации по косвенным затратам (накладным расходам), а также чисто финансовыми затратами (например, инвестиционные платежи). Учет этих затрат не ведется в рамках MRP II, единственное, что подлежит анализу - общий “прямой” финансовый результат производственной программы за плановый период. Косвенные затраты в этой методике рассчитываются по установленному нормативу от прямых затрат. Для современных предприятий характерно возрастание доли косвенных затрат в структуре затрат предприятия, и адекватный их учет способствует эффективности финансового управления предприятием. В ERP системах, в том числе и благодаря единому хранилищу данных, кроме собственно производственных затрат, должны и могут учитываться и планироваться затраты на маркетинг, предпродажную подготовку и затраты на послепродажный цикл и пр. Чтобы поддерживать высокий уровень обслуживания клиентов и минимизировать запасы, требуется развитая система планирования, обеспечивающая своевременные поставки с завода или центрального склада. Методология, разработанная для решения подобных задач, получила название DRP. DRP координирует спрос, предложение и ресурсы между подразделениями одной или нескольких компаний, обеспечивая оптимальное решение (планирование, учет и управление) транспортных задач по перемещению материально-технических ресурсов и готовой продукции. Материалы перемещаются от поставщика к потребителю по распределительной сети между поставщиками и какими-то подразделениями компании Заказчика, между этими подразделениями и клиентами или между различными подразделениями одной компании. 24. Управление внутренними ресурсами и внешними связями предприятия ERP II В развитых странах большинство корпораций внедрило у себя систему класса ERP. Некоторые даже и не по одной, т.к. риск неудачи внедрения в этой области велик даже на Западе. На смену была предложена концепция управление внутренними ресурсами и внешними связями предприятия ERPII (Enterprise Resource and Relationship Processing). Исторически развитие концепции ERPII интегрировало все отработанные ранее стандарты, что отражено на рис. 3.9. Предметная область ERP II распространяется за пределы ERP и затрагивает непроизводственные отрасли. ERP II — это результат развития методологии и технологии ERP в направлении более тесного взаимодействия предприятия с его клиентами и контрагентами. При этом управленческая информация компании не только используется для внутренних целей, но и служит для развития отношений сотрудничества с другими организациями. Рисунок 3.9 - Вложенный характер стандартов управления предприятием Помимо новой управленческой ориентации системы ERPII характеризуются и некоторыми технологическими особенностями. Здесь, прежде всего, имеется в виду Internet-ориентированная архитектура, которая существенно отличается от архитектуры традиционных ERP-систем. Это обусловлено тем, что управленческая информация, ранее хранимая и применяемая только внутри предприятия, теперь должна быть доступной (разумеется, с разумными ограничениями) для информационных систем клиентов и партнеров. Традиционная клиент-серверная архитектура начинает уступать место Web- клиентам и распределенным компонентным технологиям. Таким образом, ключевыми словами в концепции ERPII являются “сотрудничество ” и “Internet”. По мнению аналитиков, ERPII имеет большие перспективы именно потому, что она основана на самых передовых управленческих и информационных технологиях. Концепция управления взаимоотношениями с клиентом (Customer Relationship Management - CRM) основана на использовании передовых управленческих и информационных технологий, необходимых для сбора информации о своих клиентах на всех стадиях жизненного цикла (привлечение, удержание, лояльность), извлечения знаний из собранной информации и использования этих знаний в интересах своего бизнеса путем выстраивания взаимовыгодных отношений с клиентами. Результат применения стратегии состоит в повышении конкурентоспособности компании и увеличении прибыли. Концепция управления отношениями с поставщиками SCM (Supply Chain Management – управление цепочками поставок) направлена на повышение потребительской ценности продукта за счет существенного сокращения непроизводственных затрат. Появлению данной концепции управления способствовал успех внедрения технологии "Точно во время" (Just In Time), достигнутый в том числе за счет установления партнерских отношений с поставщиками. Это партнерство создало такие преимущества для обеих сторон, как улучшение смежных бизнес-процессов, разработку новых совместных продуктов и услуг, надежные и своевременные поставки, снижающие уровень запасов предприятия. Достигнуть таких результатов, невозможно без надежной организации обмена информацией. Традиционные «бумажные» системы документооборота стали уступать место системам электронного обмена данными, позволяющими организовать информационные потоки на качественно новом уровне. Дальнейшим шагом к формированию концепции SCM явилось появление систем управления производством класса ERP. По мере развития соответствующего программного обеспечения и его интеграции с ERP-продуктами корпоративные системы управления стали выходить за традиционные рамки автоматизации операций внутри предприятия. Появились и новые термины: обычный контур управления (продажи – производство - закупки) стали называть back-office (внутренней системой), а функции взаимодействия с контрагентами и заказчиками — front-office (внешней системой). 25. Понятие архитектуры предприятия Современные предприятия относятся к классу сложных систем. Эффективность системы / предприятия зависит от самых разнообразных факторов: обеспечения и связности внутренних функций, влияний внешней среды и форм взаимодействия с нею, ресурсных ограничений, а также от используемых информационных технологий (ИТ). Для решения проблем управления сложными системами достаточно давно и успешно (поскольку это направление системного анализа интенсивно развивается) используется такое средство, как моделирование. Остановимся на другой проблеме, увеличивающей сложность современных предприятий. С появлением персональных компьютеров информационные технологии стали широкодоступными во всех экономических, политических, общественных сферах деятельности. Любая современная организация имеет наборы персональных компьютеров, серверов, сетевого оборудования, программного обеспечения – все это составляет так называемую технологическую основу современной организации. С одной стороны, никто сегодня не будет оспаривать необходимость технологий в процессах организации, с другой стороны, их связь с основной деятельностью организации не является очевидной. Способом борьбы с растущей сложностью проблем на стыке бизнеса и информационных технологий стала концепция архитектуры предприятия. Архитектуру предприятия можно определять как описание (модель), представляющую в том или ином виде все составные части системы / предприятия, связи между этими частями, особенности деятельности организации и их истоки. Архитектура предприятия предназначена для выявления причинно-следственных связей между объектами и процессами основной деятельности (определяются целями и задачами организации) и информационными технологиями, поддерживающими их. Специалисты говорят, что «существует как бы «облако неопределенности» между определенными организацией целями и обеспечивающей ее ИТ-инфраструктурой» (рисунок 4.1), согласование этих различных сторон деятельности организации является сложной и до конца не решенной проблемой. Рисунок 4.1 - «Облако неопределенности» между целями организации и информационными технологиями Чтобы лучше понять особенности создания архитектуры предприятия, вспомним перечисленные выше принципы моделирования и заметим следующее: 2. С точки зрения принципа осуществимости, модель должна соответствовать поставленным целям, определяющим границы моделирования и критерии их достижимости. Любая организация обладает определенным множеством целей, которое часто можно представить в виде так называемого «дерева целей», иерархической структуры, представляющей декомпозицию (разложение) главных целей организации на составляющие, цели нижнего уровня. Возникает вопрос, как эта совокупность целей должна быть отражена в модели? 3. С точки зрения принципа информационной достаточности, система, которой является любое предприятие, является сложным объектом, многие стороны деятельности которого определены неявно. «Только часть этого общего понятия, которая в принципе доступна для восприятия архитекторами, может быть переведена в явную документируемую форму – модель или набор моделей с неизбежными упрощениями, ограничениями и субъективными искажениями. Такая проекция и представляет собой «описание архитектуры» 4. Согласно принципу множественности модели для адекватного отображения реального объекта необходимо создать ряд моделей, создающих многомерное представление оригинала. 5. Принцип агрегирования гласит, что модель должна быть представлена в виде наборов взаимосвязанных компонент. Для реализации этих принципов в создании архитектуры предприятия необходимы методологические подходы. Согласно стандарту IEEE 1471 Института инженеров-электриков и электронщиков, предоставляющему метамодель для определения архитектуры, абстрактными элементами архитектуры являются представления, системы, среды, обоснования, заинтересованные стороны и т. д. в соответствии со схемой, показанной на рисунке 4.2. Рисунок 4.2 - Рамочная модель разработки архитектуры по IEEE 1471 Здесь набор моделей генерируется как представления участников системы, согласно их точке зрения, множество моделей формирует описание архитектуры системы. 26. Эволюция понятия «архитектура предприятия» Чтобы составить представление о составе участников системы, рассмотрим эволюцию понятия «архитектура предприятия» (рисунок 4.3). В ранних работах ИТ-архитектура понималась в основном как Технологическая архитектура или архитектура, определяющая инфраструктуру информационной системы. Работы по описанию архитектуры были сосредоточены на формировании технологических стандартов и принципов, включая проведение инвентаризации различных технологий, используемых в организации. Такой подход позволяет добиться определенных частных выгод, связанных, прежде всего, с уменьшением стоимости закупок и эксплуатации информационных систем и уменьшением затрат на разработку приложений и обучение персонала. Однако он является заведомо ограниченным, так как не подразумевает ориентацию на решение бизнес-задач, таких как, например, формирование единых в масштабе компании данных по клиентам. Следующей ступенью явилось понятие Корпоративной информационно- технологической архитектуры масштаба предприятия (EWITA – Enterprise-wide information technology architecture). На этом этапе развития концепции архитектуры предприятия к технологическому уровню описания была добавлена архитектура информации и архитектура прикладных систем. Основным содержанием этого этапа была систематизация решений по использованию общих данных, обеспечению информационной безопасности, исключению дублирования бизнес-функций, координации управления пользователями, ресурсами. К преимуществам EWITA (информационно-технологической архитектуры) следует отнести систематизацию знаний по всей совокупности информационных систем предприятия, что позволяет улучшать информационное взаимодействие различных подразделений организации, например, совместный доступ к информации сотрудников подразделений, а возможно, и клиентов, поставщиков, других контрагентов, что создает основу для большей эффективности бизнес-процессов организации. Получаемые преимущества носят в основном тактический характер. Следующим логическим этапом развития эффективного описания существующих в организации процессов и планируемых изменений явилось введение понятия архитектуры предприятия (Enterprise Architecture, ЕА), в которой архитектура EWITA была дополнена описанием бизнеса организации или бизнес-архитектурой, что позволило связать информационно-технологическую деятельность со стратегическими целями организации. Такой подход должен обеспечить неразрывную связь бизнеса и поддерживающих его информационных технологий. Отвечая на вопрос, зачем для управления ИТ необходимо рассматривать бизнес организации, нужно заметить, что это позволяет связать наилучшим образом экономическую и информационную сторону деятельности организации, создавая среду для решения задачи повышения эффективности как бизнес-процессов, так и информационных технологий, в их взаимосвязи. В системе архитектуры предприятия, проще просматриваются и рассчитываются эффекты от внедрения новых информационных технологий, повышаются результаты возврата инвестиций, а также лучше планируются и контролируются расходы, связанные с ИТ. Преимуществом ЕА является способность организации быть гибкой и динамичной за счет синхронизации возможностей ИТ с бизнес-стратегией. При этом возможны варианты: 1. обеспечение альтернативности бизнес-стратегии за счет возможности изменений в обеспечивающих процессах и технологических решениях; 2. появление новых информационных технологий, возможности которых формируют новую бизнес-стратегию. Архитектура информационных технологий и архитектура предприятия создают механизм интерпретации и реализации целей организации в соответствующие им ИТ- инфраструктуру и информационные системы. Это достигается через создание определенного количества взаимосвязанных архитектурных представлений. Имеется множество методик описания архитектуры, и все они разбивают архитектуру предприятия на различное количество моделей и определений, которые относятся к таким областям, как бизнес, информация, прикладные системы, технологическая инфраструктура. Рисунок 4.3 - Эволюция термина «Архитектура предприятия» [8] Развитие понятия корпоративной архитектуры стимулировалось экономическими выгодами, которые получались при использовании того или иного архитектурного подхода. Так, появление «Технологической архитектуры» способствовало снижению затрат на ИТ, «Информационно-технологическая архитектура» позволила просчитывать и получать отдачу от инвестиций в ИТ, а «Архитектура предприятия» создала возможности органической интеграции бизнеса и ИТ. По большому счету, архитектура предприятия – это прежде всего управление знаниями, т. е. процесс сбора и распространения информации о том, как организация использует и должна использовать ИТ в своей деятельности. Включение же в архитектуру предприятия представлений о бизнес-архитектуре обеспечивает связь с возможностями оптимизации бизнес-процессов. 27. Место «архитектуры предприятия» в эволюции организационных принципов предприятия Архитектура предприятия – это способ понимания того, как организация выполняет свою работу, используя такие ресурсы, как Люди, Бизнес-процессы, Данные и Технологии. Это инструментальное средство позволяет повысить результативность и эффективность существующих в организации бизнес-процессов, а также разрабатывать и реализовывать поддерживающих их технические системы. Архитектура предприятия систематизирует и дает фиксированное описание в виде работоспособных моделей, диаграмм и функциональных описаний всех режимов деятельности данной организации. Организация использует разработанную ею архитектуру как средство управления ИТ и как инструмент, обеспечивающий то, что инвестиции в ИТ дают измеримые результаты. Архитектура предприятия как инструмент управления связана с развитием принципов организации деятельности предприятия, а именно (рисунок 4.4): 1. функциональная специализация; 2. реинжиниринг бизнес-процессов; 3. корпоративная архитектура. Рисунок 4.4 - Эволюция организационных принципов Методика использования архитектуры предприятия состоит в генерировании новых информационных проектов: строятся две архитектуры предприятия «как есть» и «как должно быть», их сравнение и выявление таких отличий порождает проекты внедрения новых ИТ, переводящих предприятие и его информационные технологии из состояния «как есть» в состояние «как должно быть». Архитектуру предприятия можно рассматривать как инструментарий, обеспечивающий знание информации о самом предприятии: организационной структуре, потоках информации, технологиях, как бы своеобразный «атлас» предприятия, позволяющий ориентироваться в выборе путей совершенствования, как в бизнесе, так и в области информационных технологий. 28. Контекст и уровни абстракции архитектуры предприятия Главным преимуществом архитектуры предприятия является целостное представление организации, системно увязывающей все области деятельности предприятия. В моделировании систем давно и успешно применяется принцип декомпозиции, позволяющий уменьшать сложность исследуемой системы за счет ее разбиения на составляющие части. Архитектуру предприятия принято рассматривать по областям, представленным на рисунке 4.5, который показывает, какие концепции могут соответствовать различным компонентам этого общего представления. Как видно из рисунка, архитектура предприятия должна отображать как аспекты, связанные с бизнесом, так и аспекты, связанные с ИТ, а также процессы развития, эволюции архитектуры и структуры управления и контроля за этими процессами, которые обеспечивают переход от текущего состояния архитектуры в будущее желаемое состояние. При описании архитектуры предприятия чрезвычайно важную роль имеют два следующих понятия: 3. перспектива или уровень абстракции; 4. представление или предметная область, домен архитектуры. Большинство методик архитектуры предприятия представляет ее как некоторое количество представлений или предметных областей (доменов), таких как: 5. бизнес-архитектура – люди и процессы; 6. архитектура информации – данные, информация и знания; 7. архитектура прикладных систем; 8. технологическая архитектура. Рисунок 4.5 - Контекст и уровни абстракции архитектуры Пользователями архитектуры являются топ-менеджмент, руководители подразделений организации, аналитики, проектировщики информационных систем, аналитики бизнес-процессов, менеджеры проектов и т. д., именно их видение различных аспектов архитектуры предприятия определяет перспективы или уровни абстракции Очень часто можно встретить следующие уровни абстракции или перспективы в анализе архитектурных областей: 9. уровень контекста – ориентирован на бизнес-руководство; 10. концептуальный уровень – ориентирован на «владельцев» бизнес- процессов; 11. логический уровень – ориентирован на архитекторов и проектировщиков систем; 12. физический уровень – ориентирован на проектировщиков и разработчиков систем. Организуя решение на различных уровнях, архитекторы способны сфокусироваться на определенном аспекте проблемы, игнорируя на время все оставшиеся пока неразрешенными сложные моменты (таблица 13) [8]. Уровень контекста описывает внешнюю среду, движущие силы и факторы, оказывающие действие на бизнес организации, видение, стратегию и то, как они влияют на деятельность организации и её приоритеты. Этот этап обеспечивает основу для всего процесса проектирования архитектуры с точки зрения основной деятельности и бизнеса организации в целом. Таблица 4.1 - Пример рассмотрения системы на различных уровнях абстракции Перспектива (уровень абстракции) Уровень детализации Контекст • Компания представляется в виде «черного ящика» и является центральным «действующим лицом» (актором). • Бизнес моделируется с точки зрения внешних для бизнеса акторов. • Моделируются только бизнес-взаимодействия, средства игнорируются. Концептуальный 7. Моделируются потоки работ бизнес-процессов, идентифицированных на концептуальном уровне. 8. Система, реализующая процессы, является центральным актором в форме «черного ящика». 9. Бизнес-процессы моделируются с точки зрения внешних для системы акторов. Рассматриваются средства коммуникаций, используемые для выполнения транзакций. Логический 8. Моделируется внутренняя архитектура системы. 9. Основные компоненты системы являются основными акторами. 10. Поведение системы моделируется с точки зрения внутренних для системы «черных ящиков». Физический 10 Моделируется физическая структура реализации системы. Результатом архитектуры концептуального уровня являются бизнес-модели, описывающие ключевые бизнес-процессы и данные, которые эти процессы используют. Следовательно, на этом уровне архитектуры предприятия детализируется, каким образом достигаются цели и требования бизнеса в форме, не зависящей от используемых информационных технологий. Логический уровень описывает решение в виде набора услуг (сервисов), компонент в независимой от технологической реализации форме. Это включает четкое определение интерфейсов (или так называемых контрактов), связанных с интеграцией и совместной работой этих сервисов и компонент. Поскольку этот уровень описания архитектуры не зависит от конкретных продуктов реализации, он остается относительно стабильным. Если мы говорим об архитектуре приложений, то логический уровень архитектуры приложения создается посредством создания модели приложений. Модели приложений описывают общую структуру прикладной информационной системы, ее компоненты и взаимосвязи между ними в терминах логической пересылки сообщений между этими компонентами, последовательности информационного обмена, общего описания данных и состояний, в которых может находиться система и ее компоненты. Таким образом, модель приложения дает некоторое логическое представление, как могут быть на практике реализованы те бизнес-модели, которые были разработаны на этапе концептуального проектирования. 29. Модель Захмана Для создания архитектуры предприятия можно использовать различные подходы или так называемые рамочные модели, методики (по-английски frameworks). Эти методики задают классификацию представлений (доменов) и принципы для их описания во взаимосвязи друг с другом, используемые правила (политики), стандарты, процессы, модели для различных перспектив. Стандартом де-факто для представления перспектив и представлений архитектуры предприятия стала схема / модель Дж. Захмана. Она послужила основой для создания целого ряда других методик и моделей описания архитектуры предприятия. Схема Дж. Захмана не дает конкретных инструментов при формировании моделей, именно поэтому её можно рассматривать как референсную модель, различные адаптации которой стали основой разнообразных методических материалов по построению архитектуры предприятия. (Референсная модель – это описанная на достаточно общем уровне структурированная совокупность понятий некоторой предметной области и их взаимосвязей, определяющая структуру данной области, главные принципы функционирования объектов данной модели и ее использования). Модель Захмана можно рассматривать как шаблон, который может быть использован в разработках различных конкретных систем. Суть новаторского предложения Захмана к построению архитектуры состояла в следующем. До него описание системы проводилось по этапам «жизненного цикла», планирование и анализ, проектирование, разработка, внедрение и эксплуатация. На каждом этапе рассматривались функции системы и данные. Захман предложил вместо описания системы в различные моменты времени использовать рассмотрение системы с различных перспектив. Исторически модель Захмана впервые была создана именно для ИТ-систем. Этот подход в последующей работе был обобщен не только для рассмотрения ИТ-систем, но и для описания предприятия в целом, так что предложенная модель, вообще говоря, может использоваться как средство для описания архитектур сложных производственных систем любого типа. Суть этого метода сводится к формализованному представлению предприятия в виде матрицы. Строки таблицы отражают уровни представления системы, к ним относятся уровни моделирования, уровни решения проектных задач. Более детально это следующие представления: • бизнес-среда системы, • концептуальная модель, • логическая модель, • технологическая, «физическая модель», • детальная реализация (часто поблочная), • представление пользователя (эксплуатация). Выделенные аспекты, столбцы таблицы фактически отражают разделы обеспечения системы: • информационное обеспечение (данные), • функциональное обеспечение (функции), • коммуникационное обеспечение (сеть), • организационное обеспечение (структура организации) и т. д. Описанные разделы обеспечения и уровни представления схемы Захмана являются классификацией сущностей предприятия и его информационной системы. Сфера действия (контекст) Модель предприятия Модель системы Технологичес кая (физическая модель) Детали реализации Работающее предприятие Рисунок 4.6 - Модель Захмана Набор архитектуры создает возможность рассмотрения системы в разрезе одних и тех же аспектов (представлений), но под разными углами зрения (перспективы). В качестве основных аспектов построения архитектур рассматриваются следующие: ◦ цели, бизнес-правила (мотивация того, почему функционирует система); ◦ объекты (что преобразуется); ◦ функции (как осуществляется преобразование в процессе); ◦ участники (субъекты) процесса (кто осуществляет процесс); ◦ место (где выполняется процесс); ◦ время (когда выполняется процесс, управляющие события). Первая строка соответствует уровню интересов высшего руководства и собрания акционеров. Во второй строке представлены модели, относящиеся к точке зрения будущих пользователей системы, владельцев процессов, третья строка соответствует взгляду консультанта-проектировщика, здесь бизнес-менеджеры, бизнес-аналитики и менеджеры, отвечающие за ИТ, должны работать вместе, четвертая и пятая строки – точке зрения разработчика ИС, шестая строка – точке зрения эксплуатационных служб. По столбцам проводится детализация различных представлений модели, например: • по представлению Данные (Что): Позиция планировщика. Приводится перечень бизнес-объектов данного предприятия (изделия, ресурсы). Позиция менеджера процесса (владельца). Представляется семантическая модель объектов бизнес-деятельности предприятия (модель предприятия). Обычно семантическая модель представляется как модель «сущность-связь». Позиция конструктора (архитектора). Описывается логическая модель данных (модель ИС). Модель представляется как атрибутивная и нормализованная модель «сущность-связь». Позиция проектировщика. Описывается физическая / даталогическая модель данных (технологическая модель). Даталогическая модель данных зависит от выбранного типа СУБД. Если выбрана реляционная технология, модель данных имеет табличную структуру. В случае объектно-ориентированных нотаций это будет иерархическая / ассоциативная модель. Позиция разработчика. Приводятся описания данных (детализированные спецификации). Определение всех объектных данных, специфицированных физической моделью данных и включающих все описания данных в соответствии с языком описания. Описания данных необходимы для реализации программы. • По представлению Функции (Как): Позиция планировщика. Описывается перечень процессов или бизнес-функций данного предприятия. Позиция менеджера процесса (владельца). Модель бизнес-процессов предприятия (модель предприятия). Позиция конструктора (архитектора). Содержит логическую модель реализации информационной системы, поддерживающую бизнес-процессы предприятия (модель информационной системы). В модели отражаются сферы действия как человека, так и машин. Позиция проектировщика. Производится конструкция системы. Это может быть структурная схема, диаграммы действий, в случае объектно-ориентированных нотаций – методы и их реализации (технологическая модель). Позиция разработчика. Программы, полученные на основе диаграмм действий или объектно-ориентированных спецификаций (детализированные спецификации). Достоинством модели Захмана является то, то она предоставляет полный набор / систему компонент, необходимых для системного представления архитектуры предприятия. К основным недостаткам традиционно относят то, что данная модель не дает описания процесса построения архитектуры, не позволяет оценивать созданную архитектуру предприятия на предмет её оптимальности. 30. Бизнес-архитектура Бизнес-архитектура определяет миссию и цели организации, показатели эффективности её деятельности (критические факторы успеха), бизнес-стратегии, функции, а также структуры и процессы, необходимые для реализации целей. Согласно модели Захмана бизнес-архитектура занимает в модели два верхних уровня (строки): контекст и концептуальную модель. В рамках модели бизнес- архитектуры выделяются следующие основные компоненты: • бизнес-процессы / цели и стратегия построения бизнеса; • организационная компонента / организационное окружение; • информация / информационное окружение; • приложения / обеспечивающее окружение. Основой адекватной бизнес-архитектуры является процессная модель: набор бизнес-процессов, их функций и характеристик. Важность процессной модели заключается в том, что результат ее анализа – совокупность требований к приложениям, обеспечивающим эти процессы. ▪ Построение модели бизнес-процессов Разработка модели высокоуровневых бизнес-процессов предприятия может производиться по следующим этапам [5]. Этап 1. Идентификация критически важных для предприятия процессов (обычно не более восьми), ключевых процессов, благодаря которым достигаются цели организации. Этап 2. Идентификация связей между этими процессами и бизнес-стратегиями, а также критическими факторами успеха. Инструментарием этого этапа могут быть, например, матрицы, где по строкам определены бизнес-процессы, а по столбцам – стратегии (или критические факторы успехов). На пересечении столбцов и строк проставляют оценки степени связи / зависимости. Оценки носят качественный характер и могут быть словесными: «сильная», «слабая». Эти же словесные формулировки можно выразить в баллах. Этап 3. Построение модели высокого уровня для ключевых бизнес-процессов. Этап 4. Для каждого процесса, указанного в модели предыдущего этапа, определить ответственных за его выполнение: функциональное подразделение организации, партнер, клиент, внешний регулирующий орган. Этап 5. Идентифицировать и документировать основные категории информационных объектов. Такие высокоуровневые модели имеют большое значение для обеспечения взаимопонимания между сотрудниками бизнес-подразделений и ИТ-служб. Модель объясняет деятельность организации в целом, связь бизнес-процессов с ключевыми факторами успеха, с вариантами реализации ИТ (варианты: готовые пакеты программ, унаследованные приложения, специально созданные заказные приложения и пр.). Высокоуровневые модели в дальнейшем декомпозируются на более детальные модели, предоставляя подробное и точное описание процесса. Важной областью использования этих моделей являются регулирование процессов планирования организационных и технологических изменений и обеспечение лучших условий для процесса принятия решений. При изучении и анализе процессов используются опыт консультантов, эталонные и референсные модели, статистические методы, применяемые в менеджменте качества. Построение таких моделей и определение их связей с ключевыми факторами позволяет понять в целом деятельность организации. Дальнейшая детализация ключевых процессов и информационных потоков достигается следующими средствами: ◦ декомпозиция функций / процессов; ◦ анализ бизнес-событий. Декомпозиция бизнес-процессов, разложение их на составляющие процессы позволяют получить описания: ◦ структуры / состава ключевых процессов; ◦ границы структурных подразделений; ◦ оценок каждой функции бизнес-процесса; ◦ недостатков существующих процессов; ◦ возможных требований к прикладным системам и информации. Анализ бизнес-событий (каждая функция должна быть инициирована событием и должна завершаться событием) позволяет определить инициатора бизнес-события, основных его участников, связанные с событием процессы, влияние события на контрагентов (поставщиков, клиентов, пр.) и его обработку в рамках такого «расширенного предприятия». При этом выявляются критически важные результаты, которые можно впоследствии использовать для введения инноваций. Конкретное событие документируется по текущим процессам его обработки и оценкам возможности его совершенствования. Модель бизнес-процессов в дальнейшем используется для определения требований к технологической архитектуре предприятия, поэтому необходимо понимать, где выполняются процессы, а также к архитектуре информации и архитектуре прикладных систем, поэтому необходимо понимать ключевые внутренние и внешние точки интеграции, основных информационных потоков между участниками бизнес- процессов. Следовательно, в рамках моделирования бизнес-процессов необходимо: 7. Моделировать местоположение выполняемых функций / процессов, обеспечивающее логистический и географический взгляд на процессы. 8. Моделировать интеграцию процессов по информации, что позволяет определять требования: ◦ к интерфейсам между процессами и бизнес-событиями, ◦ к информации для новых бизнес-процессов, ◦ ко времени работы процесса. Необходимо помнить при построении модели бизнес-архитектуры о достижении разумного баланса между детальностью и потребительскими качествами модели, её назначением. Для отражения участия информационных систем в обеспечении бизнес-процессов можно предложить следующую последовательность уточнения их роли и места: ◦ указание наименования используемой информационной системы / подсистемы на уровне процедуры; ◦ указание компоненты информационной системы / подсистемы (наименование модуля) на уровне поддерживаемой функции, реализуемой в рамках бизнес-процесса; ◦ детализация информационной системы / подсистемы как источника информации для документов и данных, используемых в бизнес-процессе. Для описания информационных потоков, циркулирующих в рамках бизнес- процесса, последовательность детализации может быть следующей: ◦ описание информационных потоков на уровне используемых операционных документов (наименование документа) и нормативных правовых актов (регистрационные номера приказа); ◦ описание информационных потоков на уровне используемых операционных сведений (данных); ◦ описание операционных документов в контексте источника информации для операционных сведений (данных); ◦ описание использования нормативной правовой базы в бизнес-процессе на уровне статей либо текстовых выдержек (пунктов приказов и инструкций), регламентирующих процедуры / функции бизнес-процесса. Для описания организационной компоненты (персонала), участвующей в процессе, можно предложить следующую последовательность детализации: ◦ указывается наименование подразделения / подразделений, участвующего в выполнении подпроцесса / процедуры; ◦ указывается должностное лицо / лица, участвующее в выполнении функции; ◦ указывается ролевая функция должностного лица / лиц, используемая для выполнения функции; ◦ устанавливается таблица соответствий между должностными лицами и ролевыми функциями, реализуемыми при выполнении бизнес-процесса на уровне функций. Детализация модели выходов может быть осуществлена в рамках такой последовательности шагов: ◦ описание результатов выходов процессов на уровне документов, продуктов, услуг; ◦ описание результатов выходов процессов на уровне данных / сведений, компонент продуктов / услуг. Назначением бизнес-архитектуры является анализ и оптимизация бизнес- деятельности организации, в том числе и её бизнес-процессов. Общая логика анализа бизнес-процессов заключается в выполнении следующих основных этапов: ◦ определение требований к основным компонентам модели (организационной, информационной), при которых обеспечивается оптимизация всего бизнес-процесса; ◦ в рамках заданных требований к компонентам модели определяются варианты оптимизации структуры модели. Процессный анализ ориентирован на получение временных, стоимостных и других ресурсных оценок бизнес-процесса с последующим выявлением «узких» мест и выдачей рекомендаций. Для проведения процессного анализа необходима специфическая среда для него, включающая: ◦ количественные показатели функций процесса по потребляемым ресурсам (организационным, информационным, техническим); ◦ механизмы учета состояния (доступности, расхода) ресурсов (организационных, информационных, технических) в ходе реализации соответствующих этапов бизнес-процесса; ◦ механизмы задания входных условий и инициализации бизнес-процесса. В результате процессного анализа выявляются: ◦ временные и стоимостные затраты на реализацию бизнес-процесса под заданные входные условия; ◦ формирование технологической карты, определяющей регламентный порядок действий должностного лица применительно к конкретной ситуации с указанием функций бизнес-процесса, в котором он задействован, принимаемыми решениями, используемыми входными / выходными операционными и нормативными документами; ◦ формирование карты временной загрузки персонала под заданные входные условия; ◦ оценка предельной «пропускной» способности организационно- технологической структуры предприятия по обработке входного потока «бизнес- событий». Процесс оптимизации бизнес-процесса можно свести к следующим шагам. Шаг 1. Должны быть заданы плановые стратегические показатели процесса. Зная их, необходимо зафиксировать требования к компонентам процесса. В результате происходит, с одной стороны, определение интегральных характеристик оптимизированного бизнес-процесса, а с другой – определение интегральных требований к основным компонентам модели бизнес-процесса, при этом не нужно на этом шаге рассматривать структуру компоненты. Шаг 2. Решение частных оптимизационных задач, направленных на проработку внутренней структуры компонент модели при жестко заданных внешних ограничениях, продиктованное целями (параметрами) оптимизации всего бизнес-процесса. То есть, исходя из заданных показателей качества бизнес-процесса (например, время, стоимость и количество обрабатываемых транзакций), на основе процессного подхода определены значения интегральных оптимизационных параметров (характеристик). Интегральные оптимизационные параметры (характеристики) бизнес- процесса трансформируются в фиксированные требования к производительности каждой из процедур (функций), которая определяется качественно-количественным составом участвующего персонала и технических систем. Имея требования к производительности процедур, составу исполнителей и технических средств организации, необходимо определить распределение и загрузку персонала и технических систем по функциями бизнес-процесса. Осуществляются детальный анализ текущей загрузки персонала, распределение ролевых (должностных) обязанностей в рамках участия в бизнес-процессах, технические возможности и распределение между пользователями технических средств, формирование должностных инструкций применительно к заданной роли. Шаг 3. Далее выбирается соответствующая архитектура моделей. Здесь важно учитывать наибольшее количество связей между различными компонентами модели, лучшим вариантом будет рассмотрение связей «каждый со всеми», что позволит учитывать всесторонние требования к компонентам модели. ▪ Структура организационной компоненты Под организационной компонентой понимаются человеческие / трудовые и технические ресурсы. Для создания модели необходима информация о распределении ресурсов по времени (по этапам реализации бизнес-процесса), по месту реализации бизнес-процесса (географическое), по стоимости ресурса, распределение ресурса в рамках реализуемого бизнес-процесса, а также о текущей доступности и текущем остатке ресурса. Качественный учет человеческого фактора в моделировании бизнес-процессов является одним из основных условий адекватности и практической ценности создаваемой модели. Трудовые ресурсы на предприятии представлены организационной структурой, для моделирования которой необходимо иметь следующую информацию по этому типу ресурса: ◦ организационно-штатная структура предприятия, уровень структуры подразделений; ◦ состав должностей; ◦ бизнес-роли (необходимо учитывать, т. к. в организации очень часто могут изменяться наименования должностей и перераспределяться должностные лица, участвующие в бизнес-процессах); ◦ функциональные обязанности должностных лиц в рамках реализуемых бизнес-процессов; ◦ временные и стоимостные затраты на выполнение бизнес-функции в рамках бизнес-процесса; ◦ временные и стоимостные ограничения на использование персонала в бизнес-процессах. Полученная информация позволит ответить на такие вопросы, как: ▪ какие функциональные задачи закреплены за конкретной организационно- штатной структурой (подразделением) в бизнес-процессах; ▪ какие временные и стоимостные нагрузки (затраты) сопровождают участие конкретной организационно-штатной структуры (подразделения) в бизнес-процессах; ▪ какие функциональные задачи закреплены за конкретным должностным лицом в бизнес-процессах; ▪ какие временные и стоимостные нагрузки (затраты) сопровождают участие конкретного должностного лица в бизнес-процессах. Получаемая информация должна позволить сделать выводы и подготовить предложения по: ▪ унификации и стандартизации ресурсов, используемых в деятельности предприятия; ▪ изменению структуры и характеристик ресурсов; ▪ перераспределению ресурсов, исходя из принимаемых решений по оптимизации (реинжинирингу) бизнес-процессов. Что касается технических систем, главным образом, автоматизированных информационных систем (АИС), то для них важно выявить существующие проблемы, такие как: ▪ одна и та же автоматизированная функция поддерживается различными информационными системами; ▪ одни и те же данные хранятся в разных информационных системах; ▪ информационные системы, поддерживающие частично пересекающийся функционал, не являются взаимозаменяемыми по составу решаемых задач; ▪ при наличии избыточности в составе автоматизируемых функций существует большое количество «не покрываемых» автоматизацией значимых бизнес- функций; ▪ отсутствие достоверной информации о том, насколько активно и в каких бизнес-процессах используется АИС; ▪ отсутствие достоверной информации по стоимостным и временным показателям использования АИС в бизнес-процессах. Информация о подобных проблемах является значимой для последующей оптимизации бизнес-процессов, она должна оказать влияние на выбор проектных решений по архитектуре организационной модели. Как правило, перечисленные проблемы относятся к информационным системам, находящимся в стадии текущей эксплуатации. Но практически аналогичные вопросы могут относиться к системам, которые предлагается внедрить: ▪ есть ли в создаваемой системе функции, которые ранее уже были реализованы в других системах; ▪ насколько экономически и организационно выгоднее использование новой системы по сравнению с существующими системами; ▪ какие новые функциональные задачи будут покрываться системой; ▪ временные и стоимостные показатели использования перспективной АИС (отдельных ее подсистем) в рамках бизнес-процесса предприятия. Полученную информацию для разработки процессно-ориентированной модели АИС можно представить так, как это сделано в таблице 4.2 Таблица 4.2 - Результаты обследования АИС организации АИС Автоматизи- рованная функция Операцион- ные данные / доку менты Поддержива- емый бизнес- процесс Время выполнения задачи процесса Стоимость выполнения задачи АИС 1 Функция-1 Документ-1 Процесс-1 Время 1.1 Стоимость 1.1 Документ-2 Процесс-2 Время 1.2 Стоимость 1.2 Функция-2 Документ-3 Процесс-3 Время 2.1 Стоимость 2.1 Документ-4 Процесс-4 Время 2.2 Стоимость 2.2 Функция-3 Документ-5 Процесс-5 Время 3.1 Стоимость 3.1 Документ-6 Процесс-5 Время 3.2 Стоимость 3.2 АИС 2 Функция-4 Документ-7 Процесс-1 Время 4.1 Стоимость 4.1 Документ-8 Процесс-1 Время 4.2 Стоимость 4.2 Функция-5 Документ-9 Процесс-3 Время 5.1 Стоимость 5.1 Документ-10 Процесс-3 Время 5.2 Стоимость 5.2 ▪ Структура информационной компоненты Информационная компонента включает в себя информационные объекты (потоки, документы, данные), которые непосредственно связаны с бизнес-процессами. Разработка информационных моделей и моделей данных представляет собой графические представления потребностей организации и отдельных бизнес-процессов в информации, которые составляются на языке, понятном бизнесу. Эти модели обеспечивают контекст, который требуется для моделирования данных. Таким образом, формируется основа для реорганизации бизнес-процессов и конструирования новых прикладных систем, описания взаимодействий и информационного обмена. Решение проблемы устранения избыточности в операционных документах, операционных данных и существенное сокращение операций по идентификации и проверке их достоверности является одним из основных резервов оптимизации бизнес- процессов. Ее решение связано с реализацией принципа обеспечения единого источника информации данных (сведений), которые в дальнейшем используются либо в документах, либо в информационных системах. При этом необходимо отметить, что элементарной единицей операционного информационного потока могут быть либо конкретные данные (сведения), либо документ. В контексте данного подхода тот или иной операционный документ может рассматриваться либо как первичный источник определенных сведений, либо как вторичный источник, то есть получатель (носитель) данных, поступивших из первичного источника (источников), например первичных документов или информационных (технических) систем, либо как самостоятельная элементарная единица операционного информационного потока. При моделировании компоненты операционных информационных потоков необходимо предусмотреть обязательное выполнение следующих шагов: 6. инвентаризацию всех операционных данных (сведений), используемых в операционном процессе; 7. установление источников по каждому данному (сведению) без категорирования источников на первичные и вторичные; 8. категорирование источников по каждому данному (сведению); 9. создание отдельных категорий объектов в информационной модели – источник, носитель (вторичный источник), информационная единица операционного информационного потока (данные либо документ), сведения (данные) с соответствующим набором атрибутов, позволяющих установить взаимные связи; 10. установление связей операционных данных и документов с фрагментами бизнес-процесса; 11. установление связей информационных источников, операционных данных и документов с нормативной правовой базой. Это позволяет решить следующие вопросы, значимые для последующей оптимизации: 12. наиболее часто используемые в бизнес-процессе операционные данные и документы; 13. ◦ неиспользуемые и редко используемые в бизнес-процессе операционные данные и документы; ◦ количество вхождений одних и тех же операционных данных в разные операционные документы; ◦ конфликтные ситуации, связанные с идентификацией точных значений данных (сведений) при их расхождении в разных источниках. ▪ Организация компоненты «Приложения» В компоненте «Приложения» должен быть дан ответ на вопрос, какие прикладные системы нужны для выполнения бизнес-процессов. Описания прикладных систем должны быть детализированы до уровня состава автоматизируемых функций, обрабатываемых (хранимых) документов (операционных данных), что обеспечивает объективное представление о значимости приложений для организации в целом. В данной компоненте должны быть оценены затраты и выгоды программного обеспечения, а также его привязка к конкретным бизнес-процессам организации. На уровне бизнес-архитектуры должна быть произведена оценка существующих информационных систем, а еще точнее, прикладных программ, используемых в бизнес- процессах. По существу, здесь уже начинается этап разработки архитектуры приложений по схеме Захмана. Выходом данной компоненты может быть портфель прикладных систем. Портфель прикладных систем, согласно [8], – это интегрированный набор информационных систем предприятия, который обеспечивает потребности бизнеса и включает в себя следующие аспекты: ◦ Имеющийся портфель прикладных систем. Это каталог имеющихся приложений и компонент, который отражает их связи с поддерживаемыми ими бизнес- процессами, интерфейсы с другими системами, используемую и требуемую информацию, используемые инфраструктурные шаблоны. ◦ Планируемый портфель прикладных систем. Представляет функциональность, которая требуется для обеспечения желаемого состояния бизнес- архитектуры и архитектуры информации предприятия. ◦ План миграции. Процесс перехода от текущего к будущему портфелю прикладных систем в рамках ИТ-проектов. Проекты также могут объединяться в портфели проектов. 31. Архитектура приложений В архитектуре приложений, как правило, выделяют две основные области: формирование и управление портфелем прикладных систем предприятия; разработку прикладных систем. Определение портфеля прикладных систем и его состава предложено в разделе Бизнес- архитектура / компонента Приложение. В портфеле должна быть определена область ответственности и приоритетность каждого приложения, а также способы его реализации: программирование (самостоятельное или заказное), покупка готового программного продукта, аренда приложения или интеграция и использование возможностей уже имеющихся приложений. Затем производится оценка текущего состояния портфеля со стратегической и технологической точек зрения. Стратегическое соответствие производится с использованием бизнес-архитектуры предприятия, оценивается вклад приложения в результативность бизнес- процесса. Технологическое соответствие оценивается по принципам и технологическим стандартам, принятым в технологической архитектуре предприятия. Существуют различные модели и инструменты такой оценки, рассмотрим некоторые из них. Оценка портфеля прикладных систем по двум критериям – ценность с точки зрения бизнеса и техническое состояние – позволяет оценить приложения по следующим категориям: Низкая ценность для бизнеса и плохое техническое состояние, рекомендации: вывод из эксплуатации (замена). Эти прикладные системы являются кандидатами на вывод из эксплуатации или замену. Низкая ценность для бизнеса и отличное техническое состояние, рекомендации: провести переоценку или перепозиционировать. Как правило, это прикладные системы, которые были недавно запущены в эксплуатацию в соответствии с рекомендациями, принятыми в рамках архитектуры предприятия. Однако по таким причинам, как, например, объем и характер решаемых ими задач или ограниченность области применения, оказывается, что их вклад в достижение ключевых бизнес-результатов незначителен. Рекомендуется идентифицировать и проанализировать возможности использования этих приложений или их компонент в рамках остальных бизнес-процессов и организационных структур предприятия. Высокая ценность для бизнеса и плохое техническое состояние, рекомендации: развивать инфраструктуру прикладной системы. Эти прикладные системы исправно обслуживают ключевые бизнес-функции, но имеются проблемы в эксплуатации и сопровождении этих систем, когда необходимо использовать информацию в других задачах, или когда требуется интеграция этих систем с другими прикладными системами предприятия. Рецептом здесь является постепенный переход на использование более адаптивной архитектуры приложения. Высокая ценность для бизнеса и отличное техническое состояние, рекомендации: обеспечить сопровождение и развитие. Эти системы критически важны с точки зрения бизнеса и спроектированы в соответствии с современными представлениями об архитектуре прикладных систем. Широкое распространение в мировой практике оценки прикладных систем получило разделение их по трем категориям (рисунок 5.1): базовые транзакционные (или вспомогательные, обеспечивающие, обслуживающие – utility); информационные (дающие преимущества); инновационные (стратегические). Классифицировать прикладные системы можно по роли, которую данное приложение выполняет в рамках портфеля информационных систем организации, например: Критически важное для предприятия в целом. Приложение чрезвычайно важно для осуществления всей миссии компании, нарушения в работе приложения могут повлечь катастрофические последствия для бизнеса. Пример: система биллинга оператора мобильной связи или система управления движением в аэропорту. 13. Критически важное для бизнеса. Приложение важно для поддержки отдельного направления бизнеса или обеспечивающего бизнес-процесса. Нарушения могут повлечь серьезные затруднения в бизнесе. Пример: система приема заказов через Интернет. Рисунок 5-1. Классы прикладных систем и их портфельная оценка 14. Вспомогательное. Некритичное приложение, решающее частную, вспомогательную задачу. Пример: система резервирования помещений для переговоров. 15. Средства офисной автоматизации. Это приложения, используемые для автоматизации повседневной работы. Типичный пример: офисные пакеты и средства подготовки презентаций. Такая оценка является только первым шагом в обеспечении соответствия между существующим и будущим портфелями прикладных систем и бизнес-стратегиями предприятия. В дополнение к этому необходимо выполнить следующее: 16. оценить те потребности со стороны бизнеса, которые вообще никак не обслуживаются существующим портфелем прикладных систем. Бизнес-архитектура должна обеспечивать список таких требований, в то время как архитектура информации должна уточнять эти требования с точки зрения информационного обеспечения; 17. провести сравнение технологических и операционных требований (надежность, масштабируемость и т. д.) портфеля прикладных систем с имеющейся технологической архитектурой с целью идентификации тех возможностей инфраструктуры, которые в настоящее время отсутствуют, но могут потребоваться; 18. согласовать проекты в области внедрения прикладных систем и развития инфраструктуры с учетом анализа на предыдущих двух шагах. Результатом должен быть синхронизированный план миграции как технологической архитектуры, так и архитектуры прикладных систем, с расстановкой приоритетов на основе определения ценностей проектов для бизнеса и технического состояния приложений и инфраструктуры. Процесс управления портфелем прикладных систем показан на рисунке 5.2. На основе сформированного портфеля прикладных систем формируются и утверждаются проекты разработки и внедрения новых приложений, которые также могут объединяться в портфели проектов. Рисунок 5.3 - Контекст управления портфелем прикладных систем Область архитектуры «Разработка прикладных систем» приложений описывает технологии, используемые для построения систем, включающие декомпозицию на функциональные составляющие, создание интерфейсов, настройку, а также используемые для этого шаблоны, руководства и т. д. Она также определяет организацию процесса разработки, используемые для этого средства, принятый на предприятии цикл разработки систем, контроль версий, управление конфигурациями, используемое программное обеспечение промежуточного слоя, средства проектирования. Независимо от выбранных границ этой области архитектуры, ее суть состоит не в ответе на вопрос, какие приложения должны быть созданы, а в выборе технологий для построения приложений и способов их применения. 32. Состав технологической архитектуры, ее назначение, используемые классификации. Преимущества классификации технологической архитектуры. Для технологической архитектуры иногда используются такие термины, как «платформы», «инфраструктура», «системная архитектура» или просто «ИТ-архитектура». Технологическая архитектура описывает аппаратное и программное обеспечение, используемое в организации, включая (но не только): 19. Аппаратные средства серверов и рабочих станций. 20. Операционные системы. 21. Средства сетевого доступа. 22. Принтеры. 23. Модемы. Технологическая архитектура обеспечивает логическое, независимое от производителей описание инфраструктуры и системных компонентов, которые необходимы, чтобы поддерживать архитектуру приложений и архитектуру информации. С этого ракурса определяется набор технологических принципов, стандартов и сервисов, которые обеспечивают руководство в отношении выбора и использования таких технологий, как аппаратные платформы, операционные системы, системы управления базами данных, средства разработки, языки программирования, программное обеспечение промежуточного слоя, сервисы электронной почты, каталоги, системы безопасности, сетевая инфраструктура и т. д. Технологическую архитектуру можно считать фундаментом, основой всего портфеля информационных технологий предприятия, на базе которой строятся и развиваются прикладные системы, обеспечивающие выполнение бизнес-процессов. Рассмотрим, какие связи существуют между прикладными системами и технологической архитектурой по функциональным и операционным требованиям, поступившим от разных областей архитектуры. Функциональные требования к прикладной системе описывают ту ценность, которую представляет система с точки зрения реализации функций организации (бизнес- ценность). Архитектура приложений, по существу, описывает все приложения, которые обеспечивают и реализуют такие функциональные требования, включая интерфейсы к бизнес- приложениям и другим прикладным системам. Операционные (или эксплуатационные, нефункциональные) требования к программному обеспечению определяют надежность, управляемость, производительность, безопасность, совместимость и др., например, возможность доступа к системе только авторизованных пользователей, уровень доступности прикладной системы 99,99% времени и т. д. Технологическая архитектура, являясь архитектурой инфраструктуры аппаратного и программного обеспечения, обеспечивает работу прикладных систем и выполнение операционных (нефункциональных) требований, предъявляемых к архитектуре прикладного программного обеспечения и информации. Она описывает структуру и взаимосвязи между используемыми технологиями и то, как эти технологии обеспечивают выполнение операционных требований организации. Поэтому можно высказать следующее утверждение: «Функциональные требования обеспечиваются архитектурой приложений, операционные требования обеспечиваются технологической архитектурой». Разработка технологической архитектуры требует классификации технологий предприятия. Рассмотрим некоторые способы построения классификации. Например, META Group выделяет два различных типа областей (доменов) технологической архитектуры: базовые (технологии, которые используются практически каждой информационной системой) и прикладные (более специфические с точки зрения использования бизнесом). Примерами базовых доменов технологической архитектуры являются сети, аппаратное обеспечение, операционные системы, системы хранения, программное обеспечение промежуточного слоя, системы управления базами данных, технологии системного управления ИТ-ресурсами в распределенной среде, архитектура безопасности. Примерами прикладных доменов технологической архитектуры являются системы коллективной работы, электронной почты и управления потоками работ (workflow), Интранет, интернет-приложения, системы электронной коммерции, архитектура хранилищ данных, специализированное аппаратное обеспечение (персональные цифровые помощники, сканеры штрих-кодов и т. д.). Согласно классификации по Gartner в технологической архитектуре выделяется шесть архитектурных компонент, каждая из которых содержит определенное количество технологических «строительных блоков». 24. Сервисы данных: системы управления базами данных (технологии баз данных и методы доступа к базам), хранилища данных (хранилища и витрины данных), системы поддержки принятия решений (BusinessIntelligence – средства анализа и средства подготовки отчетов). • Прикладные сервисы: языки программирования, средства разработки приложений (средства моделирования баз данных, репозитории, методики разработки приложений, средства обеспечения качества), системы коллективной работы (средства групповой работы и электронной почты, средства управления документами), архитектура приложений (модель компонент, серверы приложений, серверы поддержки тонких клиентов), геоинформационные системы и средства. ◦ Программное обеспечение промежуточного слоя. ◦ Вычислительная инфраструктура: операционные системы, аппаратное обеспечение, в том числе мобильные устройства, ноутбуки, беспроводные устройства, персональные цифровые помощники, серверы приложений / данных, принтеры; среда для web-инфраструктуры (браузеры, web-порталы, web-серверы, средства управления и создания контента, серверы каталогов), системы хранения (накопители на магнитных лентах, накопители на оптических дисках и CD, системы хранения высокой надежности RAID), средства системного управления (средства сетевого управления, администрирование IP), топологии (топология распределенных приложений). ◦ Сетевые сервисы: локальные сети, в том числе протоколы, кабельные системы, топология; глобальные сети; технологии доступа, в том числе удаленный доступ, эмуляция терминалов и шлюзы, беспроводные технологии для локальных и глобальных сетей, интегрированные средства передачи данных и голоса, обеспечение доступности, средства видеоконференций; голосовые технологии; сетевое аппаратное обеспечение, в том числе концентраторы, маршрутизаторы и пр. ◦ Сервисы безопасности: авторизация, аутентификация (внутренняя и внешняя аутентификация, PKI), сетевая безопасность (Network Firewall, Internet Firewall), физическая безопасность центров обработки данных, прочие сервисы безопасности (обнаружение вторжений, защита от вирусов). Реальные преимущества упорядочения технологической архитектуры и создание списка используемых технологий таковы: ◦ технический персонал должен поддерживать знания, связанные с меньшим количеством продуктов, что уменьшает затраты на персонал и обучение; ◦ прикладные системы легче интегрировать между собой, когда они имеют много общих технических аспектов. Заметим, что список технологий и поставщиков не является все-таки самым важным инструментом интеграции данных и систем. Вопросы семантики, согласования форматов и т. д. гораздо более сложны и не решаются выбором одной технологии; ◦ предприятие может получить экономию на масштабах, приобретая технологии ограниченного количества поставщиков (например, скидки на лицензии); много усилий может быть сэкономлено на процессах закупок, поскольку после того как технология однажды выбрана, последующие закупки не требуют затрат времени на длительное изучение альтернатив. 33. Роль стандартов в информационно-технологической архитектуре. Проблемы технологической архитектуры. Важность стандартов в информационно-технологической архитектуре состоит в том, что стандарты обеспечивают возможность взаимодействия различных компонент между собой. Эта роль стандартов усиливается для особенно сложных систем. Стандарты есть общепринятые документы, формализующие лучшие практики. Принято различать стандарты де-юре, эти стандарты разработаны и поддерживаются официальными органами по стандартизации, такими как Международная организация по стандартизации – ISO, и стандарты де-факто, основанные на существующем широком распространении технологии, методологии или продукта (например, использование MS Windows в качестве операционной системы для персональных компьютеров). Стандарты можно подразделять на «технологические» и «рамочные». Технологические стандарты определяют особенности реализации тех или иных протоколов, интерфейсов, языков программирования и т. п. В задачах разработки архитектуры предприятия наибольший интерес представляют «рамочные» стандарты (Framework), они задают общие требования к реализации процессов разработки и поддержки жизненного цикла систем. Эти стандарты обычно составляют методологическую основу для организации процессов жизненного цикла с необходимой конкретизацией для каждого предприятия. К рамочным стандартам относятся, например, ISO 15704 (Требования к стандартным архитектурам и методологиям предприятия), а также ISO 15288 (Процессы жизненного цикла программных средств) и, частично, ISO 12207. При разработке архитектуры предприятия достаточно широко используется также около тридцати дополнительных «поддерживающих» стандартов системной и программной инженерии. На практике предприятие для стандартизации своих информационных технологий формирует так называемые профили стандартов. Каждый такой профиль является выборкой из нескольких базовых стандартов и, может быть, других нормативных документов с четко зафиксированными подмножествами определений, обязательных к реализации. Помимо обязательных элементов, профиль может определять некоторые требования как факультативные, необязательные. Профиль не может расширять состав требований так, чтобы он противоречил использованным в нем базовым (исходным) стандартам. Профили могут создаваться как для отдельной системы, так и для класса систем, предназначенных для использования в определенных рамках. Использование профилей направлено, прежде всего, на снижение трудоемкости и стоимости разработки проектов информационных систем и повышение качества их реализации за счет использования уже апробированных решений. При этом сами профили можно условно разделить на два класса: профили, описывающие собственно программные или архитектурные решения на основе ISO 15288, и профили, регламентирующие процессы жизненного цикла программных систем, такие как разработка, тестирование, сопровождение и т. п. Обычно для этого класса за основу берется стандарт ISO 12207. ▪ Проблемы технологической архитектуры Одной из частных задач, решаемых в рамках технологической архитектуры, является задача формирования перечня закупаемых технологий. Инвестиции в инфраструктуру ИТ являются крупными и долговременными, однако их значимость для предприятия с точки зрения получения бизнес-результата неочевидна. Ценность технологий трудно определить напрямую, поскольку их влияние на бизнес является косвенным. Технологии улучшают работу приложений, приложения обеспечивают эффективность бизнес-процессов, от организации бизнес-процессов зависит результативность предприятия. Поскольку одна и та же инфраструктура обеспечивает работу приложений, обслуживающих различные бизнес-процессы предприятия, то их финансирование, как правило, производится централизованно. Рассмотрим еще одну проблему технологической архитектуры, связанной с принятием решения о размещении отдельных частей инфраструктуры. Инфраструктура может быть общей (централизованной) или локальной, находящейся в отдельных подразделениях организации. Такое решение является стратегическим и должно основываться на принятых в организации принципах построения архитектуры. На рисунке 5.4 показано, как технологическую инфраструктуру предприятия можно распределить по нескольким «уровням». Изображено предприятие с несколькими бизнес-подразделениями и набором технологий. Некоторые из этих технологий координируются и эксплуатируются централизованно, другие поддерживаются на уровне отдельных подразделений. Требования к технологиям обеспечиваются комбинацией общекорпоративной и публичной инфраструктуры. К публичной инфраструктуре относятся Интернет, телекоммуникационные сети поставщиков услуг, электронный обмен данными. Общекорпоративную инфраструктуру составляют такие технологии, как корпоративный портал, сервисы персонального компьютера и локальных сетей, электронная почта, корпоративная обработка данных, базы данных клиентов. Инфраструктура уровня подразделения ориентирована на более специфические потребности соответствующих подразделений, например, обработка заказов, управление знаниями, управление финансами. Например, в крупной компании обработка больших массивов производственных данных может производиться в едином корпоративном центре обработки данных. Все подразделения используют эту централизованную инфраструктуру, но имеют некоторые дополнительные локальные потребности, которые обеспечиваются локальной инфраструктурой. Одно из бизнес- подразделений, крупнейшее на предприятии, может и не иметь своей собственной локальной инфраструктуры, а использовать исключительно централизованные сервисы. Рисунок 5.4 - Различные уровни размещения инфраструктуры [8] 34. Информационная архитектура Архитектура информации включает в себя видение, принципы, модели и стандарты, обеспечивающие процессы создания, использования и поддержания информации, относящиеся к деятельности предприятия. Архитектура информации включает в себя модели, которые описывают процессы обработки информации (information value chain), основные информационные объекты, связанные с бизнес-событиями, информационные потоки, принципы управления информацией. Архитектура должна описывать как те данные, которые требуются для выполнения процессов (операционные), так и аналитические данные и «контент», публикуемый на Web. Задача создания архитектуры информации в концепции архитектуры предприятия не сводится к разработке информационных структур баз данных, цель ее состоит в составлении описания информации, требующейся для бизнеса, политик и правил работы с информацией, то есть об архитектуре и моделях информации, а не данных, хотя эти понятия и пересекаются. Модели архитектуры информации являются более абстрактными, они используют язык бизнеса и обеспечивают контекст, который требуется для моделирования данных. Модели данных уже предполагают четкие описания структуры объектов, атрибутов, отношений между сущностями. Понятие «архитектура информации» является расширением понятия «архитектура данных». Информация предприятия уже давно относится к его стратегическим ресурсам, и информационный домен архитектуры предприятия является частью «интеллектуального капитала» предприятия, поэтому архитектура информации должна включать такие средства, как оценка качества данных, их востребованность, учет стоимости как нематериального актива. К основным проблемам разработки архитектуры информации можно отнести использование различных типов информации, среди которых выделяют: ◦ структурированную информацию, которую можно описать реляционными и объектными моделями; ◦ полуструктурированную информацию, для представления которой используют XML стандарты; ◦ неструктурированную информацию в форме текстов, графиков, образов, сопровождаемую определенными описательными данными (метаданными и каталогами). Все эти типы информации требуют специфических технологий и методов работы с ней. Другой проблемой является множественность форматов данных и источников информации. Практически все крупные и многие средние предприятия, как правило, имеют несколько различных СУБД, а также средств управления и преобразования данных, широко используются покупные прикладные системы, каждая из которых имеет свои модели данных, что приводит к увеличению количества источников данных. К третьей проблеме можно отнести фрагментацию и дублирование информации. Данные на предприятии проходят через большое количество этапов в процессе своего жизненного цикла, при этом одни и те же данные могут обрабатываться разными прикладными системами и храниться в различных базах данных, что приводит к фрагментации данных. Это следствие работы с одной и той же информацией различных подразделений. Разработка архитектуры информации сопровождается решением следующих задач: ◦ идентификации и инвентаризации существующих данных, включая определение их источников, процедур изменения и использования, ответственность, оценку качества; ◦ сокращения избыточности и фрагментарности данных с целью уменьшения затрат на устройства хранения, стоимости их обслуживания, а также повышение качества данных за счет исключения неоднозначности и противоречивости различных экземпляров; ◦ исключения ненужных перемещений или копирования данных, особенно связанных с наличием большого количества унаследованных или устаревших приложений; ◦ формирования интегрированных представлений данных, таких как витрины и хранилища; обеспечение доступности данных в режиме, приближенном к режиму реального времени, за счет использования средств обмена сообщениями, интеграционных брокеров и шлюзов; ◦ интеграции метаданных, что позволит обеспечить целостное представление данных из различных источников; ◦ сокращения числа используемых технологий и продуктов, что позволяет снизить расходы на обслуживание, а также получить дополнительные, объемные скидки от поставщиков применяемых продуктов; ◦ улучшения качества данных, прежде всего, за счет привлечения бизнес- пользователей к управлению и определению данных; ◦ улучшения защиты данных на основе использования последовательных и согласованных мер, обеспечивающих, с одной стороны, защиту от несанкционированного доступа, а с другой – доступность данных для их использования на практике. Архитектура информации включает в себя следующие области (а также связанные с ними стандарты, руководства и пр.): ◦ метаданные; ◦ моделирование данных; ◦ системы управления базами данных; ◦ программное обеспечение промежуточного слоя для доступа к данным; ◦ механизмы доступа к данным; ◦ безопасность данных. 35. Распределенные системы. Корпоративная политика распределенных вычислений. Распределенный процесс – это метод выполнения компьютерной программы с более чем одним процессором, расположенных в различных местах. Цель распределенного процесса состоит в том, чтобы переместить соответствующую обработку настолько близко к пользователю, насколько это возможно, и позволить другим машинам выполнять ту работу, которая у них получается наилучшим образом. Например, когда агент туристической фирмы использует свой компьютер, чтобы оформить перелет, который требует более одной авиалинии, система бронирования билетов связывает компьютеры различных авиакомпаний, чтобы оформить маршрут. Процесс бронирования становится возможным, благодаря многочисленным операциям компьютеров, вероятно, с несколькими базами данных, согласно специфическому требованию покупателя. Распределенная технология требует операционной совместимости, которая означает способность различных машин, использующих различные операционные системы в различных сетях работать совместно над задачей. Операционная совместимость позволяет обмениваться данными и стандартными процессами, не требуя изменений в функциональности и без физического вмешательства. Различают следующие типы операционной совместимости. Тип «Связь между процессорами» означает, что каждый процессор в распределенной системе может послать данные и сообщения любому другому процессору по электронному коммуникативному соединению. Желаемая структура надежной распределенной системы имеет, по крайней мере, два независимых пути между двумя любыми узлами, разрешающая автоматическую альтернативную маршрутизацию, в случае один из узлов выйдет из строя. Плановая избыточность такого типа – критична для надежности операций. «Общесистемные правила» означают, что операционная дисциплина для распределенных систем разработана и неизменно применяется. Эти правила регламентируют, как распределенные вычислительные устройства осуществляют коммуникации друг с другом: С 1990-х годов эти общесистемные правила в значительной степени основывались на концепции открытых систем. Продукты, использующие открытые стандарты, могут работать совместно в одной или более распределенной системе, такой как Интернет. Первоначальная идея была избежать несовместимости продуктов собственной разработки одного поставщика или нескольких поставщиков. Вообще говоря, чем сложнее распределенная система, тем сложнее правила. В 1980-х понятие открытых систем относилось главным образом к телекоммуникациям и означало, что компания намеревалась реализовать продукты, которые следуют стандартам Референтной модели OSI (Open System Interconnection). Около 1990 г. определение открытых систем расширилось до включения операционных систем, особенно Unix, потому что Unix работал на многих платформах, больше чем какая-либо другая операционная система, и Unix не принадлежал ни одной компании. В то время Unix предположительно рассматривался как подходящая ОС для обработки данных в бизнесе. Сегодня это важная операционная система для серверов Интернета. В обработке данных бизнеса Unix занял устойчивое положение, но не сместил фирменные операционные системы, такие как MS Windows. В то же самое время в области данных «открытый» означало структурированный язык запросов (SQL), стандартный посреднический язык для доступа к реляционным базам данных. SQL остается стандартом и сегодня. Вначале 90-х определение открытости сдвинулось к программному интерфейсу. Открытый стал означать стандартизованные интерфейсы, что позволило взаимодействовать различным продуктам в сети, в которой используются программы или оборудование различных производителей, операционные системы и базы данных. Интерфейсы прикладных программ (APIs) появились на свет. Они определяли способ для представления данных другим компонентам системы – оборудованию, базе данных, даже системе электронной почты. Сегодня термин «открытый» включает все упомянутые определения и усиливает взаимосоединяемость. В этой сфере референтная модель OSI остается определением открытости. Большинство людей, однако, знакомы только с наиболее широкой его реализацией: сетевой протокол, используемый в Интернет,TCP/IP. Корпоративные сети, и LAN, и WAN, теперь используют TCP/IP, чтобы облегчить соединение с Интернет. Интересный поворот в определении термина «открытый» набрал критическую массу не так давно. Вначале открытые системы позволили программистам предлагать ПО бесплатно (или за небольшое добровольное пожертвование), что многие и делали. Такое ПО было названо «открытым источником», что означает, что код источника может быть загружен любым и может быть модифицирован. (В покупном ПО код компилирован и не поддается расшифровке). Направление открытых источников привело к тому, что разработчики брали такое ПО, улучшали и перерегистрировали в Интернет. В 1990-х Линус Торвальдс предложил свою операционную систему Linux как открытый источник, он приобрел с тех пор огромное количество поклонников. Разработчики по всему миру дополняли систем, улучшали и распространяли. Потому что она была бесплатной, она использовалась огромным количеством компаний. Термин «открытая система» продолжает расширяться, потому что это действительно решающий вопрос распределенных систем, обеспечивающий совместную работу продуктов различных производителей. Хотя некоторые усматривают главную причину распределенных систем в улучшении использования компьютерных ресурсов, то есть только в технической операционной совместимости, переносимости и открытых стандартах ПО. Организационные стимулы распределенных систем состоят в переносе ответственности за компьютерные ресурсы на тех, кто использует их в этом взаимосвязанном мире. Относительно недавно многие главные вендоры, такие как IBM или Hewlett-Packard, начали использовать Linux как часть своей комплексной стратегии продаж. С открытым ПО эти вендоры продолжают удерживать своих покупателей и концентрируются на разработке специфических решений для бизнеса. Это направление критически важно в компьютерном мире. Во-первых, оно помогает связывать компьютеры, используемые в бизнесе быстрее и эффективнее по стоимости. Во-вторых, это вероятно ускорит конечную потребность в стандартизации открытых источников. ▪ Корпоративная политика распределенных вычислений Информационный менеджмент нуждается в корпоративной политике для решения, когда развитие, эксплуатация и техническое обслуживание приложений должно стать распределенным. Перед тем как распределенные ИТ процессы и ответственность за них будут определены, необходимо задать следующие три вопроса о бизнесе. Взаимозависимы ли операции? Когда важным для операции является знание о том, что делает другая операция, такие операции называются взаимозависимыми; таким образом, их планирование, модернизация ПО, ресурсы машин и операции необходимо централизованно координировать, чтобы синхронизировать операции. Две отрасли, в которых взаимозависимость является критически важной, - это обрабатывающая промышленность и авиаперевозки, которые вот поэтому продолжают оставаться сильно централизованными системами, даже в эру распределенных систем. Является ли бизнес действительно однородным? Если операциям не нужно знать, что делают другие операции, тогда многие системные функции могут быть децентрализованы, если операции действительно не имеют много общего. Например, в бизнесе быстрого питания (фастфуда) каждая франшиза (право на производство и продажу продукции другой компании) требует одинаковых информационных процессов, что делает их однородными. Но им ничего не надо знать друг о друге, следовательно, они не взаимозависимы. При таких обстоятельствах процессы могут быть распределенными, а планирование, модернизация ПО, подбор аппаратного обеспечения должны быть централизованны, чтобы снизить стоимость процессов и более легко проникать в новые системы. Решение о том, являются ли информационные процессы в разных частях бизнеса однородными, не всегда очевидно. Например, не все торговые сети одинаковы. Один из ведущих продавцов обнаружил, что необходимо создать две информационные системы для обработки платежей кредита, одну – для высококлассных магазинов, другую – для магазинов уцененных товаров. Потребности этих двух типов магазинов так различны, что единственная система не может их удовлетворить. Однако, корпоративные информационные отделы контролируют планирование, которое создает продавцу способность быстро схватывать маркетинговые возможности, когда он может использовать систему настроенную на любую операцию. В практике многих крупных организаций применяется централизация планирования, но для исполнения разрешается децентрализация на уровне пользователей. Поддерживает ли корпоративная культура децентрализацию? Даже если все направления бизнеса совершенно различны, и у них нет никакой необходимости знать о том, что другие делают, корпоративная культура может настаивать, что некоторые функции должны оставаться централизованными. Например, для большой компании с 60 сильно различающимися подразделениями может показаться логичным распределить все функции, однако, менеджмент выбрал централизацию таких функций как финансы, управление человеческими ресурсами и системное планирование. Они хотят предложить возможность карьерного роста в масштабе всей компании с как можно меньшей переквалификацией. C центральным штатом, делающим планирование систем и координацию, компания может более легко перемещать людей и повторно использовать системы. Если нет ни одного из этих критериев – взаимозависимость, однородность, корпоративная культура – сил централизации, каждая бизнес единица может направлять свою собственную деятельность по ИТ, с центральной организацией, контролирующей планы. 36. Типы распределенных систем организации ▪ Иерархия, основанная на хостах Иерархия процессоров была первой структурой распределенных систем. Эта структура была очень популярна у производителей мэйнфреймов, так как большие хост-компьютеры на вершине иерархии контролировали терминалы внизу. Более чем один уровень процессоров мог быть частью иерархии, как показано на рис. 5.5, с общей рабочей нагрузкой, разделяемой между ними. Важная характеристика этой структуры состоит в том, что хост компьютер является центральной управляющей компонентой. Другой важной характеристикой является то, обработка производится на компьютерах. Терминал – это устройства доступа (ввод, вывод), они сконструированы таким образом, что не могут обрабатывать данные, и не имеют устройств для хранения данных. Рисунок 5.5 – Иерархия, основанная на хостах ▪ Децентрализованные автономные системы Децентрализованные автономные системы в действительности не являются формой распределенных систем, они децентрализованы, но не распределенные (см. рис. 5.6). В течение ряда лет такие «островки обработки данных» развивались и до сих пор еще используются. Их архитектура монолитна в программах обработки данных, самих данных, интерфейсах, вся обработка происходит в самой системе. Они были связаны, чтобы разрешить проходить малому потоку данных, но этот поток направлен, главным образом, наверх к корпоративному хосту. Рисунок 5.6 – Децентрализованные системы ▪ Одноранговые системы, созданные LAN LAN (локальная вычислительная сеть) стала основой распределенных систем настольных компьютеров с 1980 г. Этот подход начался в офисных системах, в которых LAN обеспечивала связь между компьютерами, серверами печати и портами для других сетей. Компьютеры в одноранговой сети (Р2Р) обычно имели одинаковые возможности и обязанности. Они отличаются от конфигурации «клиент-сервер», в которой несколько компьютеров предназначено для обслуживания других. Одним из вариантов применения Р2Р является такой: компьютеры расположены физически рядом и работают по одинаковым сетевым протоколам и программному обеспечению. Как показано на рис. 5.7, эта структура не имеет иерархии и зависимости сверху вниз. Рисунок 5.7 – Одноранговые сети ▪ Гибридные системы масштаба предприятия Типичная структура распределенных систем сегодня основывается на этих трех формах распределенных систем, связанных между собой тремя видами сетей: LAN, WAN, Internet. Эти системы показаны на рис. 5.8. Современные распределенные системы смешивают и сочетают иерархическую хостовую (основанную на хостах) обработку, пользующуюся преимуществом в вычислительных процессах корпораций и Web-сайтах совместно с ведомственной обработкой данных, предпочитаемой такими ведомствами как производство и машиностроение, системы, основанные на LAN, используются в офисах. Такая гибридная структура должна вероятно стать предпочтительной структурой на долгие годы по мере того как компании связывают свои «островки» автоматизации и все больше и больше связываются с системами других организаций. Нужно отметить, что в гибридном подходе необязательно, что корпоративный хост управляет всеми компьютерами. Фактически ряд компаний заменил совсем свои центральные компьютеры, рассеяв приложения по ведомственным машинам и серверам. Хост-компьютер, показанный на рис. 5.8, не является центральным управляющим устройством. Для некоторых приложений это может быть хост, для других – это всего-навсего другой сервер. Второе важное замечание заключается в том, что такая структура позволяет компаниям автоматизировать бизнес-процессы, охватывающие несколько функций внутри организации или работающим совместно с системами других предприятий. Обработка данных между предприятиями является догматом электронного бизнеса. Например, Expedia.com связывает свою В2С систему бронирования отелей со своими поставщиками, доставляя своим клиентам доступ к большому выбору отелей. Такие совместные процессы позволяют компаниям иметь преимущество специализированных компьютерных программ, в то же самое время, увеличивая полезность некоторых унаследованных (старых) систем. Процесс сплачивания таких различных приложений или компонент называется системной интеграцией. Рисунок 5.8 – Гибридные системы 37. Системы «Клиент-Сервер» В 1990-х появились системы «клиент-сервер», чтобы иметь преимущество в производительности обработки данных на хост-машинах и ПК-х в одной и той же системе. Хотя хост регулирует работу огромных баз данных и процессы обработки заказов, ПК, ноутбуки и еще более мелкие устройства могут создавать графики, звук и даже видео, которые были очень важны в некоторых приложениях. Обработка данных в технологии «клиент-сервер» разделяет рабочую нагрузку компьютера между клиентом, компьютером, делающим запрос, и сервером, отвечающим на запрос. Запрос может быть на печать документа (управляется сервером печати по сети LAN) или запрос на номер порта выхода на посадку в самолет, опаздывающим на рейс – требование, посланное с сотового телефона с Интернет возможностями, с такси и обслуживаемое Web-сайтом аэропорта. Рисунок 5.9 – Клиент-серверные системы Сеть представляет разделяемую линию между тем, что расположено на клиенте и тем, что расположено на сервере. Три разделяемых компонента – это человеко-машинный интерфейс (HCI, Human Computer Interface), Приложения и Управление информацией. Кратко, слева направо спектр выглядит следующим образом: 11. Распределенный человеко-машинный интерфейс содержит все данные, все прикладное ПО и некоторую часть интерфейса на сервере. Только часть человеко-машинного интерфейса расположена на клиенте. Такой подход является одним из способов оставить старые унаследованные с мэйнфреймами системы в том же состоянии, в то же время модернизируя экраны пользователя. 12. Удаленный человеко-машинный интерфейс включает весь человеко-машинный интерфейс на клиенте машины, но оставляет программы (приложения) на удаленном сервере. Этот подход обеспечивает способ сохранения старых унаследованных систем и только модернизацию интерфейса, видимого пользователем. Он был использован для обеспечения обработки транзакций в бэк-офисном режиме веб-сайтов. 13. Распределенная функция приложений для бизнеса, в которой все ПО находится на стороне клиента, а данные – на сервере, прикладное ПО распределяется между клиентом и сервером. Этот выбор довольно сложен, потому что процесс распределения приложений между двумя машинами требует координации. Однако, это может быть наиболее удобный выбор для приложений, работающих в пакете программного обеспечения, таких как электронные таблицы, текстовый процессор, на клиенте в комбинации с корпоративными приложениями на мэйнфрейме. Это может быть удобным для беспроводной обработки данных и для основных интерфейсных приложений, таких как ввод заказа, запрос инвентаризации и т.п. Системы электронной почты используют эту альтернативу: часть обработки на клиенте, часть – на сервере. 14. Удаленное управление данными, в котором все ПО помещается на клиенте, оставляя только данные и управление данными на сервере. Этот выбор популярен, поскольку он содержит все прикладное ПО в одном месте (на «толстом» клиенте) и создает преимущества, заключающиеся в огромной производительности обработки данных современных ПК. Хотя такое решение менее сложно, оно имеет недостаток, заключающийся в том, что в требовании одновременной модернизации всех компьютеров новой версией ПО. Обеспечение такого уровня координации может быть очень трудным, если только компьютеры не находятся под жесткой организацией системы управления, которая в заданном порядке обновляет их, когда они связаны в единую вычислительную сеть. 15. Распределенные базы данных, в которых все презентационное и прикладное ПО, а также некоторые данные расположены на клиенте. Оставшиеся данные находятся на сервере. Это достаточно сложное решение, в особенности, если многочисленные базы данных работают синхронно. Несмотря на это, технология очень важна в обработке данных на мобильных устройствах, где, например, каждый продавец может нуждаться в данных, хранящихся локально (вероятно, это те данные, которые редко изменяются). Оперативные данные (вплоть до секунды) могут храниться в главной базе данных быть доступными по мере необходимости. Это решение также основано на «толстом клиенте». Другой способ рассмотрения систем «клиент-сервер» состоит в представлении их архитектуры. Предпочтительной архитектурой являлась трехуровневая. Как показано на рис. 5.10, уровень 3 –это высокопроизводительный сервер, возможно, мэйнфрейм или кластер серверов Web. Он может быть связан напрямую с корпоративной клиент-серверной сетью, или он может быть связан с ней через серверы второго уровня. Недолговечные и быстроизменяющиеся данные, также как соответствующие правила целостности, хранятся на уровне высокопроизводительных серверов с тем, чтобы данные могли разделяться. Уровень 3 Суперсервер, часто мэйнфрейм, подключен к сети через один или несколько серверов, иногда напрямую Уровень 2 Несколько специализированных серверов, некоторые из них предназначены для промежуточного слоя Уровень 1 Клиенты, некоторые из них могут Быть мобильными устройствами Рисунок 5.10 - Направление трехуровневой клиент-серверной компоновки Уровень 2 – специализированные серверы. Специфичные для подразделения или рабочей группы данные хранятся здесь, также данные, которые не должны слишком часто обновляться, и которые еще требуют быстрого поиска. Уровень 2 также вмещает промежуточный слой, т.е. ПО, которое облегчает соединение клиентов и серверов. Промежуточный слой становится важным понятием в клиент-серверных системах, т.к. он осуществляет трансляцию между различными системами. При наличии промежуточного слоя многие приложения, написанные на UNIX, могут быть легко установлены в системах, поддерживающих Windows или Linux, без необходимости их переписывать. Уровень1 – компьютерные вычисления конечного пользователя, соединенные через некоторый вид сети. Альтернативной архитектурой является двухуровневая, которая состоит из клиентов и серверов, или клиентов и мэйнфрейма. Трехуровневая архитектура уменьшает сложность клиента, сокращая число интерфейсов, которые нужно разместить на машине клиента. Недостаток состоит в том, что клиенты являются более сложными, и доступ к данным уровня 3 медленнее, чем к уровню 2. Клиент-серверные системы использовались, чтобы оптимизировать рабочие процессы, способствуя совместной работе людей через сеть, давая им силу локальной вычислительной мощности, а также доступ к другим людям и внутренней и внешней информации. Наиболее сильным преимуществом является то, что клиент-серверная обработка данных поддерживает новые организационные структуры, обеспечивая их взаимосвязанность. Создавая платформу, поддерживающую индивидуальную и групповую работу, географически рассредоточенную, что позволяет компаниям экспериментировать с географически разобщенными рабочими группами. Фактически, эксперименты с этими технологиями и их инфраструктурой дают компаниям возможность легче получить преимущество Интернета. Это как бы большая клиент- серверная система. Однако, клиент-серверные системы не имеют затраты ниже, чем системы, основанные на мэйнфреймах (как сначала рекламировалось), потому что они требуют слишком много усилий по координации и поддержке. То, что вначале выглядело просто как связанность между клиентами и серверами превратилось в большую, часто нестабильную, сложную систему. Хотя клиент- серверные системы проще для конечных пользователей, ежедневное управление ими более сложное, благодаря следующим обстоятельствам: ПО операционных систем распределено по сотням отдельных машин вместо единой монолитной системы; рабочие станции географически разбросаны с множеством нестандартного аппаратного обеспечения (от сканнеров до настольных принтеров) и контролируется разными подразделениями. Здесь могут быть некоторые дополнительные непрямые затраты такие как: потери в производительности рабочих и выявление дополнительных рисков, связанных с безопасностью. Большой бизнес пробовал автоматизированные инструменты для администрирования рабочих станций с центральным расположением. Обновленные программные модули могут устанавливаться автоматически, как только пользователь аутентифицирует себя на центральных серверах. Также рабочие станции могут быть сконфигурированы для решения различных проблем безопасности. ◦ Основанная на Интернет обработка данных Основанную на Интернете обработку данных можно изобразить как простой компьютер, который взаимодействует с другими вычислительными устройствами через Интернет. Вначале предполагалось, что сетевые компьютеры – без жесткого диска, только браузер, клавиатура, модем - получит доступ к сети Интернет. Если компьютеру необходимо совершить некоторую функцию, он получит ее из Интернет. Концепция настольных сетевых компьютеров не отбрасывалась, но концепция использования программ в Интернете получила преимущество в мире портативных устройств. Компьютерное (вычислительное) пространство разделяется между толстым клиентом (обычный ПК, загруженный всеми программами) и тонким клиентом (устройствами, использующими программы, удаленного доступа). Концепция тонкого клиента часто используется для извлечения небольших программ (апплетов) из Web, написанных на Java, языке программирования, созданного специально для Интернета. 38. Серверные вычисления. Вычисления в одноранговой сети. Серверные вычисления можно рассматривать как стиль обработки данных «более тонкий клиент», т.к. возвращает обработку данных обратно на сервер, где они могут централизованно управляться. Со все большим и большим числом служащих, имеющих офисы в своих ноутбуках, возрастают проблемы безопасности и оперативные проблемы. У ноутбуков нет хороших характеристик по безопасности, обновление их скопом дело нелегкое, а даже индивидуальные загрузки могут требовать поддержку службы технического сопровождения. Решение компаний – возвращение к серверным вычислениям, где приложения и наиболее жизненно важные данные предпочтительно помещаются на корпоративные серверы, а не настольные компьютеры. При серверных вычислениях доступ к приложениям с любого устройства безопасен, они могут обновляться непосредственно на сервере, и они не должны быть адаптированы для работы на специфической машине. Как обсуждалось ранее, серверы могут быть централизованно управляемыми, более безопасными и реализованными по более низкой стоимости, чем типовая клиент-серверная конфигурация. Однако, существует несколько скрытых затрат в этой архитектуре. Это системное решение подходит для бизнеса, который практикует удаленную работа или работу на дому, когда нет большого разнообразия в потребностях к компьютерной обработке данных. ▪ Вычисления в одноранговой сети В Р2Р (одноранговых сетях) задачи распределяются по широкому набору компьютеров (равноправных), объединенных Интернетом. Это - массовое движение, подобное тому, что происходит на основе открытого исходного кода, но многие корпорации относятся к нему вполне серьезно. Возможно наиболее спорным примером Р2Р является Napster, центральный каталог музыки и ПК, на которых эта музыка находится. Пользуясь ПО Napster, люди могут находить названия музыкальных произведений на сайте Napster и скачивать музыку с зарегистрированных на нем ПК. Каждый обменивается друг с другом. Napster не известен, потому что музыкальная индустрия утверждает, что нарушили законы об авторском праве, поощряя музыкальное пиратство. Его в конце концов закрыли. Автор, Джереми Рифкин, говорит, споры о Napster находятся в центре понимания двух экономик: «старой» экономики, которая делается покупателями и продавцами, и электронной экономикой, в которой есть клиенты и обслуживание (серверы). Кроме Napster, полезными широко используемыми применениями Р2Р являются разделение файлов, обмен мультимедиа, мгновенные сообщения и воспроизведение. Преимущества одноранговых вычислений: 11 Множество источников, соединенных вместе через крайне низкое по стоимости взаимодействие, делают общую или коллективную информационную базу более ценной, чем сумма изолированных частей. 12 Стоимость взаимодействия чрезвычайно низка, вследствие использования уже существующей инфраструктуры и минимизации расходов на техническое обслуживание (или стоимости, ложащейся на пользователей). 13 Одноранговые системы обеспечивают Анонимность / Приватность. Р2Р системы могут быть устроены таким образом, чтобы предоставить ее членам высокую степень автономного контроля над своими данными и ресурсами. С другой стороны, безопасность становится реальной проблемой. Проблема состоит в том, как приобрести выгоду из Р2Р среды. Полагают, что подписка заменит продажи. Люди будут предпочитать платить за доступ, а не за собственность. Зачем покупать один CD диск, когда вы можете иметь неограниченный доступ к постоянно растущей гигантской музыкальной коллекции на месяц. На физических рынках приобретаются физические свойства. На сетевых приобретается доступ к опыту. Когда гиперскорости и непрерывные изменения станут нормой, будет меньше смысла иметь в собственности, а больше смысла подписываться. 39. Web сервисы. Стандарты Web сервисов. Только что описанные формы Интернет вычислений можно рассматривать как первое поколение Интернет-распределенных систем. Web сервисы стали вторым поколением. Термин относится к модулям ПО, имеющим URL, т.е. Интернет адрес, посредством которого они могут быть вызваны, чтобы совершить свою работу (функцию, как сервис) через Интернет. Спроектированные на основе принципов объектно-ориентированного подхода, Web сервисы являются компьютерными программами, которые делают запрос к другим Web сервисам для выполнения их задачи (или набора задач) с возвращением результата. Некоторые специалисты называют это транзакционным Web, и они полагают, что эта технология будет доминировать во взаимодействии «программа-программа», «бизнес –бизнес». В сущности, множество Web сервисов, вызывающих друг друга, образуют сильно (высоко) распределенную систему. Такие системы с посылкой сообщений позволят системам одной компании работать с системами во многих других компаниях без необходимости определять в коде конкретные значения переменных вместо того, чтобы получать их из внешних источников для связи систем друг с другом. Фирмы, чтобы установить взаимодействие могут пользоваться стандартами ПО и коммуникационными протоколами. Многие эксперты по технологиям предсказывают, что Web сервисы будут окончательной формой рыночных распределенных систем. Необходимые процессы обработки данных можно будет вызывать по запросу, и по согласованной цене последовательность Web сервисов будет собрана, чтобы выполнить этот запрос. Традиционно последовательность шагов должна была быть предрасположена (предварительно запрограммирована) загодя. Динамическое связывание Web сервисов происходит во время их выполнения, что делает системы намного более гибкими. По существу, Интернет становится хабом в обработке данных, который нацелен на то, чтобы сделать более простыми совместную обработку данных предприятий (то, что многие предприятия хотят избежать, потому что это сопряжено с большими инфраструктурными издержками). Web сервисы, вероятно, могут освободить компании от создания и сопровождения большого количества внутреннего ПО. Перспектива заключается в том, что они могут сдавать в аренду функциональность через Web сервисы по подписке или по мере необходимости. Web сервисы будут опираться на существующие системы. Web сервисы могут использоваться как оберточные технологии. Компании могут обернуть (инкапсулировать) некоторую функциональность существующих приложений в XML конверт и выставить (экспонировать) их для использования другими, объявляя об их существовании в некотором специальном каталоге. (Два новых термина используются в мире Web сервисов «обертка» и «экспонирование»). Таким образом, банк, имеющий систему авторизации кредитной карты, может предложить ее для использования как Web сервис за дополнительную плату. Или компания, дающая возможность покупателям конфигурировать заказываемые продукты онлайн (компьютеры, велосипеды, автомобили), может на самом деле использовать Web сервис (созданный самой компанией или приобретенный у третьей стороны), чтобы предложить его функциональность на Web сайте для людей или компьютерам своих крупнейших клиентов. Не нужно говорить, что вендоры сейчас наперебой будут провайдерами платформ, на которых работают Web сервисы. Компании экспериментируют с Web сервисами или проверяя эту слабосвязанную сервисно-ориентированную архитектуру в самостоятельно, или надежным торговым партнером. Стандарты Web сервисов Мир Web сервисов станет возможным благодаря трем стандартам ПО (XML, WSDL,UDDI) и трем коммуникационным протоколам (SOAP, HTTP, TCP/IP) отмечают специалисты. • XML (eXtended Markup Language). XML – это язык для описания данных стандартным способом, для того чтобы разные приложения могли использовать эти данные. Web сервисы создаются обертыванием XML частей ПО, реализующих некоторую функциональность. XML обертка описывает услуги, которые пакет предоставляет. • WSDL (Web Services Definition Languages). Web сервисы объявляют себя, публикуя описания в XML документе, для которого необходим WSDL. Это объявление дает описание сервиса, как сделать запрос к нему, необходимые для его работы данные, результаты, которые будут предоставлены. WSDL обеспечивает стандарт языка для создания таких описаний, таким образом они становятся понятными для тех, кто собирается запрашивать этот сервис. • UDDI (Universal Discovery, Description and Integration). Описания хранятся в UDDI регистрах, «желтых страницах» Web сервисов. Приложение или Web сервис могут найти другой Web сервис, или зная его URL, или осуществляя поиск в UDDI репозиториях для сервисов нужных параметров. • SOAP (Simple Object Access Protocol). Web сервисы взаимодействуют, используя SOAP, коммуникационный протокол, основанный на XML, работающий с любыми сетями и с любым оборудованием. Web сервисы взаимодействуют друг с другом, посылая требования на обслуживание другому сервису, напрямую связываясь с ним и вызывая его. Оба сервиса не нуждаются в перепрограммировании для того, чтобы работать совместно. Web сервисы могут сочетаться в любых моделях использования. • HTTP (Hypertext Transfer Protocol). Web сайты имеют адреса, которые используют HTTP протокол. Web сервисы опираются на этот же протокол для указания адреса, по которому они расположены. • TCP/IP (Transmission Control Protocol/Internet Protocol). Интернет имеет правильное имя, он действительно сеть сетей, потому что использует протокол, позволяющий передавать сообщения по сетям. Этот протокол - TCP/IP, и этот протокол используется Web сервисами также. Значение Web сервисов Специалисты полагают, что Web сервисы – это компьютерная архитектура будущего, следовательно, ожидаются большие изменения в работе CIO. Вместо того, чтобы иметь и поддерживать свои собственные системы, компании будут покупать себе технологии как сервисы через Интернет. Следовательно, в ближайшие несколько лет старые правила управления ИТ будут пересмотрены. Web сервисы предлагают совершенно новую ИТ-архитектуру, основанную на Web и открытости. Web сервисы могут быть собственными, общими, на некоторые будут подписываться, другие будут по требованию. Специалисты видят такую трехуровневую сервисную архитектуру: • Сервисы приложений – это верхний уровень. Они предназначены для специфической деятельности бизнеса: обработка кредитных карт, планирование отгрузки, анализ кредитного риска. • Сетка сервисов – средний уровень. Он предоставляет утилиты, используемые сервисами приложений. Первый тип утилит – это разделяемые утилиты, такие как безопасности (аутентификация запрашивающих, и авторизация доступа), биллинга (ведение счетов) и оплаты (регулирование сборов за использование Web сервиса). Другой тип утилит – это утилиты управления сервисом, которые регулируют менеджмент и оплату Web сервисов. Утилиты управления знаниями ресурса, третий тип, обеспечивает каталоги и регистраторы для запрашивающих и сервисов, нашедших друг друга. Утилиты управления транспортировкой, четвертый тип, регулируют посылку сообщений и файлов. Пока эта сервисная сетка не прочна, хотя компании не будут использовать Web сервисы для своих наиболее важных задач, потому что они не хотят их делать в открытой среде. • Стандарты ПО и коммуникационные протоколы расположены в нижнем уровне. Они обеспечивают основу для утилит и сервисов приложений. Без этих стандартов и протоколов Web сервисы не смогут говорить на одном языке, не связываться друг с другом. Чтобы продемонстрировать потенциал Web сервисов, рассмотрим кредитные заявки. Вместо того, чтобы иметь большое интегрированное внутреннее приложение, управляющее всеми шагами в процессах утверждения и финансирования заявки, каждый шаг в среде Web сервисов будет совершаться различными Web сервисами. Фактически, Web сервисы будут настолько специализированны, что наиболее приемлемые из них могут быть выбраны на каждом шаге процесса в реальном времени. Следовательно, данные заявки из больницы будут посланы в Web сервис, специализирующийся на анализе рисков медицинских заявок, в то время как данные заявки от ресторанов будут посланы в Web сервис, специализирующийся на анализе рисков кредитования заявок. Каждый из этих Web сервисов может опираться на другие специализированные функциональности, чтобы обслуживать еще более специализированные процессы, зависящих от данных заявок и заявленной суммы финансирования. Эта особенность позволяет регулировать огромное множество возможностей путем смешивания и сопоставления. Вдобавок это позволит облегчить соединение систем компаний- контрагентов. В результате компании платят только за используемую функциональность только тогда, когда они ее реально используют, что сокращает ИТ активы компании, необходимые для их внутреннего размещения и содержания. Провайдеры регулируют сопровождения своих собственных сервисов и вынуждены оставаться в курсе конкурентной природы рынка Web сервисов. Продвижение в направлении Web сервисов потребует организационных изменений в ИС. Это требует аутсорсинга функций ИТ провайдерам (по мере их появления) и разработке собственных Web сервисов, основанных на деловой проницательности своего предприятия. Далее следует пример такого предприятия. ◦ Корпоративная ИТ Инфраструктура в Цифровой Экономике Дискуссия, проходящая через всю главу, состоит в том, что доступность информации и создание вычислительных сетей являются важными элементами новой экономики. Они важны для фирм, сохранивших свою конкурентоспособность. Они важны для фирм, пытающихся кооперироваться в глобальном масштабе. Главное здесь состоит в том, что CIO должен помочь в руководстве организации таким образом, чтобы она стала активным субъектом сетевой экономики. Проактивный (активный, инициативный) бизнес – это такой бизнес, который знает, как использовать Интернет-технологии для настройки ИТ инфраструктуры, чтобы наилучшим образом поддерживать стратегию бизнеса в цифровой экономике. Стратегии могут быть следующими: Расширенное предприятие: Расширенное предприятие – это такое предприятие, которое включает не только из своих работников, менеджеров, акционеров, но и своих поставщиков и покупателей. ИТ-инфраструктура – это взаимосвязанная информационная вычислительная сеть, которая помогает всем участникам принимать лучшие решения и координировать бизнес-процессы таким образом, чтобы они улучшали общие показатели работы. Таким образом, эта стратегия сфокусирована на Интернет поддержке менеджмента цепи поставок и создание стоимости вследствие эффективного информационного менеджмента. Стратегический альянс: Альянсы позволяют участвующим организациям разделять ресурсы, усиливать свои конкурентные позиции и усваивать уникальные сильные стороны своих партнеров. Альянсы обычно создаются для исследований и развития, технического обмена, совместного производства и дистрибуции продаж. В то время как традиционные предприятия асимметричны, стратегические альянсы более симметричны в своем сотрудничестве. Как только отрасль становится зрелой и их перспективы роста становятся низкими, в сочетании с навыками проведения инноваций, в то время как разделение затрат на НИОКР становится все более насущным. Множество гигантских организаций таких как Воинг, Дженерал Электрик, ИБМ и Роквел сформировали стратегические альянсы. Решение по ИТ предприятия должно состоять в поддержке совместной работы партнеров. Разделяемые данные и процессы должны быть монолитными, в то же время должны быть защищены собственные данные. Информационному менеджеру следует изучить навыки использования менеджмента знаний и инфраструктурной интеграции, внедрения встраиваемого программного обеспечения, межплатформенного программного обеспечения, программного обеспечения для бизнеса для разработки ориентированных на сетевую интегрированную компьютерную платформу для конкретных проектов на основе существующей инфраструктуры. Виртуальная организация: В виртуальной организации участники географически разделены, возможно, независимых и юридических лиц, но работающих вместе как единая производственная организация с реальным физическим расположением, пытающаяся решить хорошо определенную задачу. Как только задача завершена, и миссия закончена, виртуальная организация растворяется до тех пор пока не будет вызвана к жизни новыми задачей. Технологии, которые поддерживают виртуальную организацию могут быть простыми средствами автоматизации офиса (текстовый процессор, табличный процессор, база данных, управление потоками работ (workflow), программа управления проектами), коммуникационное ПО (электронная почта, доска объявлений, Web-портал), а также ПО обеспечения масштаба предприятия (ERP, CRM). Вне обычного контекста бизнеса, хорошо документированным и подобным научной фантастике примером виртуальной организации является Second Life, запущенной в 2003 г., но ставшую известной публике несколько лет позже. Абонент может использовать загружаемую клиентскую программу, чтобы увидеть других людей, общаться, участвовать в индивидуальных и групповых мероприятиях, а также пользоваться торговыми объектами и услугами. К 2007 году здесь было более чем 8,5 миллионов зарегистрированных резидентов и аккаунтов. Концепция виртуальной организации также демонстрирует тенденцию к динамичному миру, где скорость и эффективность – ключ к выживанию, также как к процветанию. И снова, ориентированная на вычислительные сети инфраструктура ИТ является основной технологией 40. Трехуровневая сервисная архитектура 41. Три представления инфраструктуры 42. Корпоративная ИТ инфраструктура в цифровой экономике 43. Место процессов управления ИТ в организации 44. Отечественные стандарты в области ИТ. ГОСТ 34.601-90, ГОСТ 34.602-89 45. Российские аналоги стандартов ISO Среди процессных стандартов в области ИТ есть несколько основополагающих разработок ISO, сыгравших важнейшую роль в становлении процессного подхода к управлению ИТ. Рассмотрим российские аналоги стандартов ISO, т. е. ГОСТы, в названии которых присутствует сочетание "Р ИСО". Они представляют собой аутентичные официальные переводы стандартов ISO на русский язык. В области управления ИТ это прежде всего ГОСТ Р ИСО/МЭК 12207-99 "Процессы жизненного цикла программных систем" и тесно связанные с ним ГОСТ Р ИСО/МЭК 16326-2002 (Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом) , ГОСТ Р ИСО/МЭК 15271-2002 (Информационная технология. Руководство по применению ГОСТ Р ИСО/МЭК 12207) и ГОСТ Р ИСО/МЭК 14764-2002 (Информационная технология. Сопровождение программных средств). Одно из центральных мест здесь занимает стандарт ГОСТ Р ИСО/МЭК 12207 "Процессы жизненного цикла программных систем" (ГОСТ 12207, 1999) - один из самых известных и распространенных процессно-ориентированных стандартов в области управления ИТ. Ссылки на него встречаются практически во всех работах и методиках, относящихся к процессам управления ИТ. Модель жизненного цикла стандарт определяет как "структуру, состоящую из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающую жизнь системы от установления требований к ней до прекращения ее использования". Методологическая основа ГОСТ Р ИСО/МЭК 12207 - разбиение процессов на группы, которых в стандарте вводится три. • Основные. Это процессы, непосредственно относящиеся к жизненному циклу информационной системы. Можно считать, что это производственные процессы организации. • Вспомогательные. Это процессы, предназначенные для поддержки основных процессов. Сами по себе эти процессы организации не нужны - только в связи с основными процессами, которые они обслуживают. Несколько процессов из этой группы связано с управлением качеством. • Организационные. Это общекорпоративные процессы, такие как "Обучение" или "Управление". Эти процессы существуют в организации независимо от того, как организовано производство и как устроены вспомогательные процессы. • Таблица 3.1. Структура процессов жизненного цикла программных систем по ГОСТ Р ИСО/МЭК 12207 • • Цель стандарта - определить полную совокупность процессов, которые могут выполняться в • ходе проекта по созданию программной системы. Но поскольку проекты могут сильно различаться, например, по масштабам, сложности, рискам и т. п., допускается для каждого проекта локально видоизменять использующиеся в нем процессы, исключая или добавляя отдельные работы и задачи. • Внедрение ГОСТ Р ИСО/МЭК 12207 - очень непростая задача. Прежде всего, непонятно, что значит "внедрить ГОСТ Р ИСО/МЭК 12207"? Можно ли считать его внедренным, если некоторые процессы организации совпадают с процессами стандарта, а некоторые - нет? Можно ли считать стандарт внедренным, если часть проектов выполняется в соответствии с ним, а часть - нет? Этот перечень вопросов можно продолжать и продолжать. • Неслучайно следом за ГОСТ Р ИСО/МЭК 12207 был разработан специально посвященный задаче его внедрения стандарт ГОСТ Р ИСО/МЭК 15271-02 (ГОСТ 15271, 2002), который называется "Руководство по применению ГОСТ Р ИСО/МЭК 12207". • В целом стандарт ГОСТ Р ИСО/МЭК 15271 производит впечатление сугубо вспомогательного по отношению к ГОСТ Р ИСО/МЭК 12207 документа, страдающего приблизительностью и обилием общих мест. Для управленцев-практиков он непригоден - слишком много абстрактных рассуждений и слишком мало конкретики. Для студентов и специалистов, изучающих процессы управления ИТ, он лишен широты взгляда на предмет (все-таки он ограничен ГОСТом Р ИСО/МЭК 12207) и перегружен ненужными техническими подробностями. Тем не менее знакомство с ГОСТ Р ИСО/МЭК 15271 полезно, поскольку он показывает направление мысли специалистов в сфере управления ИТ, демонстрирует, куда и как развиваются современные стандарты. Его можно рассматривать как промежуточный рабочий документ, хотя и имеющий форму стандарта, но предназначенный скорее для обсуждения в заинтересованной аудитории специалистов по управлению ИТ. • Еще одна попытка формализовать процесс применения ГОСТ Р ИСО/МЭК 12207 была предпринята в стандарте ГОСТ Р ИСО/МЭК 16326 "Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом" (ГОСТ 16326, 2002). Он демонстрирует попытку объединить процессы жизненного цикла из ГОСТ Р ИСО/МЭК 12207 с процессами управления проектами из популярного методического справочника PMBOK1) (PMBOK, 2009) и стандарта ISO 10006 (русская версия стандарта содержится в (ГОСТ 10006, 2005)). Схематически это • представлено на рис. 6.3, приведенном в стандарте. • • Рисунок 6.3 – Наполнение стандарта ГОСТ Р ИСО/МЭК 16326 • ГОСТ Р ИСО/МЭК 16326-2002 по форме и назначению не отличается от ГОСТ Р ИСО/МЭК 15271- 2002. И тот и другой страдают избытком правильных "в общем" и опирающихся только на здравый смысл рассуждений. Эти рассуждения очевидны для каждого, кто имеет практический опыт • руководства проектом, и вряд ли выглядят обоснованными для тех, кто такого опыта не имеет. В отличие от ГОСТ Р ИСО/МЭК 15271-2002 стандарт ГОСТ Р ИСО/МЭК 16326-2002 более • формален, но практический смысл предложенного формализма непонятен. • С точки зрения практического применения при проектировании бизнес-процессов, связанных с ИТ, оба стандарта по большому счету бесполезны. С другой стороны, они могут оказаться востребованными при выполнении комплексных проектов, включающих наряду с исследованием практики управления ИТ анализ проектного управления и управления качеством. • ГОСТ Р ИСО/МЭК 15288 (СИСТЕМНАЯ ИНЖЕНЕРИЯ. Процессы жизненного цикла систем) Здесь принцип разделения процессов на группы - абсолютной иной, нежели в ГОСТ Р ИСО/МЭК 12207. На первый план выдвигаются бизнес-цели, на достижение которых работают процессы. Иерархия ответственностей, предлагаемая стандартом, конечно, не единственно возможная, но сама идея привязки процессов к ответственностям представляется очень плодотворной. Это помогает привязать процессы к структуре организации, определить в ней владельцев процессов. Таким образом, становится более структурированной задача внедрения стандарта, возникают связи между бизнес-целями организации и результатами деятельности владельцев процессов. По итогам изучения стандартов делается вывод об отсутствии к настоящему времени единого взгляда на процессы управления жизненным циклом. 46. Модель ITIL v.2 47. Модель ITIL v.3 Все указанные стандарты переносят идеологию стандарта менеджмента качества ISO 9000 на процессы управления ИТ. Существуют и стандарты, возникшие непосредственно из различных методик, применяемых для совершенствования информационной сферы деятельности, и которые, действительно востребованы на практике. До середины 80-х гг. перед менеджерами крупных компаний не стояла задача управления ИТ. Тенденции 80-х и 90-х годов в развитии ИТ имели результатом, с одной стороны, удешевление вычислительных мощностей, с другой стороны, появление новых проблем, не существовавших прежде. Они были обусловлены тем, что затраты на ИТ многократно увеличились, в то время как отдача от таких вложений была гораздо более спорной, чем когда-либо ранее. Массовое применение ПК повысило производительность труда работников, но не сказалось на повышении производительности организации в целом. В 1990 годы под эгидой правительства Великобритании был начат широкомасштабный сбор и анализ передовой практики организации бизнес-процессов ИТ. Этот проект получил название ITIL – IT Infrastructure Library. Принципиально важный момент проекта состоял в отборе успешных проектных решений по управлению ИТ – вне зависимости от их соответствия той или иной теоретической концепции. Результаты анализа издаются в виде постоянно обновляемой библиотеки работ, которые охватывают основные бизнес-процессы ИТ, поддающиеся обобщению. Отметим среди полученных результатов некоторые наиболее универсальные: 10. Основная задача информационной службы предприятия – сопровождение существующей ИТ-инфраструктуры. Этот вывод может показаться тривиальным, однако, на деле не является таковым. Широкое распространение ПК породило представление о простоте разработки программ для них. В результате основной задачей информационных служб представлялось немедленное удовлетворение потребностей пользователей посредством разработки решений на основе офисных приложений Word/Excel/Access. Практика показала, что полученные таким образом продукты могут быть использованы в лучшем случае как прототипы решений. Приложения, автоматизирующие процессы компаний, должны основываться на промышленных и, как правило, покупных решениях. 11. В рамках сопровождения ИТ-инфраструктуры информационная служба обслуживает бизнес-подразделения, удовлетворяя потребности бизнеса предприятия. 12. Бизнес-подразделения потребляют не информационные системы, а услуги ИТ, т.е. решение проблем бизнеса средствами ИТ. Эти решения бизнес оценивает не только по предоставляемой функциональности, но и по качеству обслуживания. Наибольшую эффективность процесса обеспечивает придание взаимодействию бизнес-подразделений и информационных служб рыночного (если информационные службы и бизнес-подразделения относятся к независимым друг от друга юр. лицам, т.е. в случае полного аутсорсинга функций информационной службы) или квазирыночного характера (в этом случае объем услуг, оказываемых информационными службами бизнес- подразделениям фиксируется в стоимостной форме, а расчет за услуги производится из бюджетов бизнес-подразделений). Приведенные результаты при всей их внешней очевидности означают серьезное изменение модели управления информационной службы. Столкнувшись в середине 1980-х с необходимостью обеспечения совместной работы разнородных систем, информационная служба сосредоточила свои усилия на построении оптимальной архитектуры информационной среды компании. Объектом управления в этом случае становились информационные системы, а целью управления – обеспечение технической возможности их совместного использования. В результате цели поддержки бизнеса были подменены техническими целями, что и привело к падению отдачи от ИТ. Модель взаимодействия бизнеса и ИТ-организации при таком подходе состоит в периодическом обмене запросами на услуги и предоставлении запрошенных услуг. Попытки регламентировать управление ИТ-услугами начались в 80-е годы прошлого века в Великобритании по инициативе правительственного Центрального Агентства по вычислительной технике. В результате была создана, вероятно, самая известная и широко распространенная эталонная модель процессов управления ИТ-услугами, получившая впоследствии название Управление ИТ-услугами (ITSM1) ) и изложенная в нескольких книгах, составивших так называемую библиотеку ITIL2). После ряда доработок в 2001 году была опубликована вторая версия ITIL, которая стала де-факто стандартом в области управления ИТ-услугами и послужила теоретической основой ряда программных продуктов, предназначенных для автоматизации управления ИТ-услугами. В качестве примеров можно назвать HP ITSM компании Hewlett-Packard, IT Process Model компании IBM, MOF компании Microsoft. Появление и распространение второй версии ITIL (для краткости - ITIL v.2) привело к созданию некоммерческой организации itSMF (от англ. IT Service Management Forum), которая имеет целью распространение идей ITIL, проведение конференций и форумов, организацию обучения ITIL. Книга (itSMF, 2003) стала фактически общепринятым введением в ITIL для начинающих. Дальнейшее изложение ITIL v.2 опирается на эту книгу. Основное содержание ITIL v.2 составила эталонная модель процессов управления ИТ- услугами, приведенная на рис. 6.4. Как видно из рисунка, процессы делятся на две группы: процессы, связанные с предоставлением услуг, и процессы, направленные на поддержку услуг. Это отражает очень простую идею разделения оперативной деятельности (поддержка услуг) и деятельности по планированию (предоставление услуг). Особняком стоит бизнес-функция, которая называется Службой Service Desk - она представляет собой не процесс, а структурное подразделение или бизнес-единицу, ответственную за оперативное взаимодействие с пользователями, т. е., по существу, "единое окно" для пользователя. Рисунок 6.4 - Процессы управления услугами ITIL v.2 Процессная модель ITIL v.2 отличается конкретностью и прагматичностью. Процессы подробно описаны в едином шаблоне, включающем не только перечень активностей, но и блок- схемы, описания ролей и ответственностей, критические факторы успеха, метрики и многое другое. Все описания предельно конкретны и не допускают никаких двусмысленных толкований. Помимо эталонной процессной модели из ITIL v.2 в управленческую практику пришло несколько фундаментальных принципов, важность которых полностью подтвердилась со временем: 16. перечень услуг, оказываемых ИТ-организацией бизнесу, фиксируется в специальном документе (Соглашении об уровне услуг) и не может быть изменен иначе как в рамках специальной процедуры; 17. отношения ИТ-организации с бизнесом носят договорной характер; стороны заранее договариваются о способах контроля за соблюдением договорных условий; 18. корпоративная оценка ИТ-организации базируется на показателях эффективности процессов оказания услуг. Кроме того, в ITIL v.2 входит процесс Управления финансами, который включает, в частности, деятельность по выставлению счетов за оказанные услуги; это означает, что ITSM позволяет рассматривать деятельность ИТ-организации как бизнес по оказанию ИТ-услуг. Фактически ITIL v.2 сформировал основы взаимоотношений ИТ-организации и бизнеса. Естественное развитие подхода ITSM состояло в том, чтобы распространить эти принципы с взаимоотношений, связанных с оказанием инфраструктурных услуг, на все взаимодействия ИТ- организации и бизнеса. Шаг в этом направлении был сделан в ITIL v.3. Основным объектом управления в ITIL v.2 была сложившаяся ИТ-инфраструктура. ИТ- организация, управляющая ИТ-инфраструктурой, предоставляла пользователям со стороны бизнеса ИТ-услуги, реализованные на базе этой инфраструктуры. Процессы, связанные с поддержкой и предоставлением услуг, а также бизнес-функция взаимодействия с пользователями (Service Desk) и составляли содержание ITIL v.2. ITIL v.3 представляет собой попытку теоретически переосмыслить и максимально обобщить как процессную модель, базирующуюся на понятии услуги, так и область ее применения. Как следствие, на первый план вышли такие вопросы, как природа услуг, связь услуг с целями и стратегией бизнеса, экономика услуг. ITIL v.3 не ограничивается услугами, связанными с управлением существующей инфраструктурой, хотя и включает процессы из ITIL v.2. С точки зрения ITIL v.3, к услугам можно отнести, например, проектирование и разработку приложений, внедрение эффективных процессов управления ИТ, закупку лицензий ПО. Кратко сформулируем основные идеи ITIL v.3. 14 Для предоставления услуг своим клиентам компания выполняет бизнес-процессы, использующие разные ресурсы, в том числе и информационные (приложения, процессы управления ИТ, ИТ-персонал, специальные знания). Та совокупность работ бизнес-процесса, которая непосредственно связана с применением ИТ-ресурсов, является предметом интереса ITIL v.3 и представляет собой услугу, которую бизнесу предоставляет ИТ-организация. Термин "ИТ-услуга" резервируется (как правило) только за "низкоуровневыми" услугами ИТ-организации, т. е. внутренними услугами ИТ-организации, имеющими технический характер (доступ к данным, приложениям, серверному оборудованию, телекоммуникациям и т. п.). 15 Взаимодействие ИТ-организации с бизнесом происходит на языке услуг, причем потребителями услуг могут быть не только люди, но и бизнес-процессы, другие услуги и даже приложения. Определение услуги формируется совместно, исходя из требований бизнеса (а в конечном итоге, его клиентов) и возможностей ИТ-организации (возможно привлечение и третьих сторон - внешних провайдеров). Какие для этого необходимы ресурсы и как они должны быть устроены - дело ИТ-организации. 16 Связь услуг ИТ-организации со стратегией бизнеса обеспечивается через бизнес- процессы: услуги ИТ-организации в первую очередь реализуются для тех процессов, которые являются критичными с точки зрения стратегии бизнеса. 17 Все решения, относящиеся к модернизации информационных ресурсов (процессов, приложений, персонала и т. п.), принимаются только в связи с услугами, которые ИТ-организация предоставляет с помощью этих ресурсов. 18 ИТ-организация находится в договорных отношениях с бизнесом. Перечень услуг ИТ- организации согласован и утвержден представителями бизнеса. Он является основой всех формальных соглашений и пересматривается только в рамках установленной процедуры. Более того, ИТ-организация, фактически, ведет свой собственный бизнес: проводит маркетинговую работу, изучает технологические новации и на основе этого планирует инвестиции в создание, модификацию, предоставление и улучшение услуг. Стоит заметить, что такой подход постоянной адаптации ИТ-инфраструктуры к изменяющимся требованиям бизнеса в известной степени противоречит распространенной практике комплексной автоматизации путем "разового" внедрения интегрированных систем, сопровождающегося массовым реинжинирингом бизнес-процессов. Более естественным с точки зрения ITIL v.3 выглядит путь постепенного внедрения приложений и интеграции их с использованием, например, принципов сервис-ориентированной архитектуры. Большое значение в ITIL v.3 являются понятия Портфеля услуг, тесно связанное с понятием Каталогом услуг. Портфель услуг - это описание услуг провайдера (например, ИТ-организации) с точки зрения ценности их для бизнеса, т. е. для потребителя услуг. Это описание разрабатывается и поддерживается самим провайдером и позволяет ему отвечать, например, на следующие вопросы: 19. Почему потребитель должен приобрести эти услуги? 20. Почему он должен приобрести эти услуги у нас? 21. Как устроены модель цены и схема взаиморасчетов? 22. В чем наши сильные и слабые стороны, приоритеты и риски? 23. Какие ресурсы и способности нам понадобятся? Под способностями ITIL понимает способности управлять ресурсами. Способности и ресурсы - активы провайдера, которые он использует для создания ценности. Управление портфелем услуг, согласно ITIL v.3, - это "динамический метод управления инвестициями в управление услугами в масштабах всей организации с целью повышения их ценности". Портфель не сводится к перечню услуг, приложений, материальных активов или проектов. Портфель прежде всего характеризует и структурирует совокупность инвестиций провайдера. Ключевыми понятиями в управлении портфелем услуг являются понятия бизнес-услуги и ИТ-услуги. Точного определения бизнес-услуги не приводится, но по смыслу это связующее звено между бизнесом и ИТ-ресурсами организации. В глоссарии бизнес-услуга определяется как "ИТ- услуга, непосредственно поддерживающая бизнес-процесс, в отличие от инфраструктурной услуги, используемой провайдером ИТ-услуг для внутренних целей и невидимой бизнесу". Согласно ITIL, Проектирование ИТ-услуг - часть глобального процесса изменения бизнеса. Этот процесс связан с жизненным циклом ИТ-услуг так, как показано на рис. 6.4 Рисунок 6.4 – Жизненный цикл ИТ-услуги Каталог услуг представляет собой главный источник информации об ИТ-услугах, предоставляемых организацией - провайдером услуг. Это означает, что все сферы бизнеса могут видеть точную, согласованную картину ИТ-услуг, их описания и статусы. Каталог позволяет потребителю увидеть, какие услуги используются, какие предполагается использовать, какие бизнес-процессы их используют, а также ожидаемый уровень качества услуг. Часто имеет смысл включать в Каталог услуг иерархию услуг, точно указывая, что за услуга располагается на каждом уровне иерархии (например, "бизнес-услуга", видимая потребителю, или "инфраструктурная услуга", рис.6.5). Инфраструктурные услуги, такие как услуги сети, услуги приложений, хотя и невидимы для потребителя, также должны быть включены в Каталог услуг. Таким образом, иерархии могут содержать потребительские и связанные с ними услуги: поддерживающие, разделяемые и услуги, связанные с предоставлением потребителю физических объектов. Рисунок 6.5 – Иерархия услуг ИТ-организации 48. Методология СММ Замечательный практический инструмент, созданный в рамках процессного подхода к описанию деятельности проектной организации, в частности, организации, разрабатывающей информационные системы, демонстрирует методология СММ. CMM расшифровывается как Capability Maturity Model, что по смыслу означает примерно "модель зрелости системы управления". В литературе CMM чаще называют моделью зрелости организации. История возникновения СММ такова. В конце 80-х гг. прошлого века Министерство обороны США заказало Институту программной инженерии Университета Карнеги-Меллон работу по созданию системы критериев для выбора субподрядчиков в проектах разработки программного обеспечения. Работа была закончена в 1991 г., и результатом ее стала модель CMM. Нужно сразу оговориться, что модель не содержит никаких финансово-экономических, политических, организационных критериев выбора субподрядчика, равно как и критериев возможности допуска к секретным работам (вероятно, такие задачи и не ставились). Речь идет только о критериях, описывающих способности потенциального субподрядчика в части разработки программных систем. "Лесенка уровней" СММ получила широкое признание и распространение. Уровень 1 "Начальный". Производственный процесс в целом характеризуется как создаваемый каждый раз под конкретный проект, а иногда даже как хаотический. Определены лишь некоторые процессы, и успех проекта зависит от усилий индивидуумов. Уровень 2 "Повторяемый". Установлены основные процессы управления проектом, позволяющие отслеживать затраты, следить за графиком работ и функциональностью создаваемого программного решения. Установлена дисциплина процесса, необходимая для повторения достигнутых ранее успехов в проектах разработки подобных приложений. Уровень 3 "Определенный". Производственный процесс документирован и стандартизован как для управленческих работ, так и для проектирования. Этот процесс интегрирован в стандартный производственный процесс организации. Во всех проектах используется утвержденная адаптированная версия стандартного производственного процесса организации. Уровень 4 "Управляемый". Собираются подробные количественные показатели производственного процесса и качества создаваемого продукта. Как производственный процесс, так и продукты оцениваются и контролируются с количественной точки зрения. Уровень 5 "Оптимизирующий". Постоянное совершенствование процесса достигается благодаря количественной обратной связи с процессом и реализации в нем передовых идей и технологий. Рисунок 6.6 - Распределение групп ключевых процессов по уровням зрелости В определениях уровней (см. рис. 6.6) появилось такое понятие, как "производственный процесс". Оно же присутствует и в определении группы ключевых процессов, и это не случайное совпадение. Производственный процесс, или, как он точно называется в СММ, Стандартный Производственный Процесс Организации (СППО), - одно из центральных понятий всей модели. "Фундаментальной концепцией определения процесса в CMM является Стандартный Производственный Процесс Организации (СППО). СППО является рабочим определением основного процесса, регулирующего установление общего производственного процесса для всех проектов разработки ПО внутри организации. На уровне организации создается описание СППО, осуществляется его контроль, управление и усовершенствование, выполняемые формальным образом. На уровне проекта в центре внимания оказывается эффективность проектного производственного процесса и его польза для проекта. Производственный процесс проекта - это производственный процесс, используемый в конкретном проекте. Он представляет собой четко охарактеризованный и понятный производственный процесс, описанный в терминах программных стандартов, процедур, инструментов и методов. Этот процесс разрабатывается путем адаптации СППО к конкретным характеристикам проекта. На первом уровне организация еще не научилась выполнять проекты с предсказуемым результатом. На втором уровне организация выполняет отдельные проекты, но по-разному, в зависимости от специфики проекта. Качественный скачок происходит на третьем уровне, когда организация создает универсальный производственный процесс, единый для всех проектов и характеризующий не отдельные проектные команды, а организацию в целом. Для этого на третьем уровне вводятся группы ключевых процессов "Определение производственного процесса организации" и "Координация производственного процесса организации". 6.4.1 Практическое использование CMM. Проект SPICE Удачная попытка SEI по созданию модели зрелости организаций - разработчиков ПО породила волну подражаний применительно к другим проектным организациям (подчеркнем, что проектный характер деятельности - одна из концептуальных основ СММ). Появилось желание регламентировать процесс создания аналогов и обобщить подход СММ, избавившись от специфики разработки ПО. В результате была разработана Концептуальная модель CMMI - СMM Integration. Цель работы состояла в том, чтобы, проанализировав и обобщив опыт разработки СММ-подобных моделей для разных видов деятельности, создать интегрированную методику оценки развитости и совершенствования процессов организации, разработка интегрированного подхода к совершенствованию процессов организации. Сама по себе CMMI не рассматривает многие домены архитектуры (данные, интеграция, безопасность, архитектуру ИТ-операций и т.п.). Кроме того, она приводит основные задачи (например, определить метрики для процессов), но не описывает, как именно нужно это делать, т.е. не содержит рекомендаций. Тем не менее, предложенный в рамках моделей CMM/CMMI подход оказался настолько удачным, что аналогичные шкалы уровней зрелости стали широко применяться и в смежных областях, которые не ограничиваются только разработкой программного обеспечения, • в том числе, управления поставками, кадровыми ресурсами или бизнес-процессами предприятия в целом (cм., например, http://www.bptrends.com). Для наших целей наиболее интересно рассмотреть применение модели к оценке процесса разработки ИТ-архитектуры, а также процессов управления ИТ в организации – как в целом, так и для отдельных подпроцессов. Пример оценки зрелости процесса управления ИТ-активами более подробно будет рассмотрен далее. Шкала уровней обычно использует обозначения от 0 (отсутствие процесса) до 5 (оптимизированный процесс). • Несуществующий Какой-либо заметный процесс управления ИТ-системами в организации отсутствует, более того, отсутствует понимание необходимости такого процесса вообще. • Начальный/Cпонтанный В организации можно найти подтверждение признания необходимости организации процесса, однако реальные мероприятия осуществляются не систематически и зависят от конкретного случая. Характерно хаотическое управление со стороны руководства, а обсуждение ведется спонтанно и непоследовательно. Существует некоторое представление о необходимости учета влияния ИТ на бизнес-процессы, но эти связи не определены. Вопросы мониторинга работы ИТ-систем обычно поднимаются только после очередных инцидентов с информационными системами, приводящими к потере данных или другому конфузу. • Повторяемый, но интуитивный В организации существует общая осведомленность по вопросам управления ИТ-системами. Проводятся мероприятия по планированию развития системы, организации мониторинга, определению показателей работоспособности. Эти мероприятия могут быть формально включены в общий процесс развития с участием высшего руководства. В организации выделены некоторые критичные для бизнеса ИТ-процессы, для которых определены основные показатели и способы их измерения, осуществляется планирование развития и инвестиций, возможно, в рамках общего подхода. В то же время эти процессы не охватывают всю организацию, формальное обсуждение стандартов и обучение стандартам не проводится. Решение вопросов во многом зависит от конкретных исполнителей. Средства управления процессом используются недостаточно полно и широко, прежде всего, из-за отсутствия опыта и практики. • Определенный Необходимость управления ИТ хорошо понятна и принята всей организацией. Разработана, документирована и внедрена базовая система ключевых показателей работы ИТ-систем, связанных с требованиями бизнеса. Все процедуры стандартизованы, описаны и доведены до сведения персонала. Значения показателей регистрируются, и тенденции их изменений отслеживаются, что создает предпосылки для инноваций в масштабе предприятия. Выбраны и применяются на практике стандартизованные средства, в том числе, основанные на концепции системы Сбалансированных показателей Balanced Score Card. В то же время прохождение обучения и применение стандартов на практике еще сильно зависят от инициатив конкретных исполнителей. Мониторинг ИТ-показателей осуществляется, но их изменение, вызванное влиянием проявленных инициатив, может быть не замечено или не оценено руководством. Тем не менее, в организации определена ответственность за эти показатели, которая находит отражение в системе оплаты руководителей и специалистов ИТ- служб. • Управляемый и измеримый В организации существует полное понимание вопросов управления ИТ на всех уровнях, подкрепленное формальным обучением. Взаимоотношения между поставщиками и потребителями ИТ-услуг регулируются на основании соглашений об уровне обслуживания (SLA). Коллективная и индивидуальная ответственность полностью определена. Все участники процесса осведомлены о возможностях ИТ, их преимуществах для развития бизнеса и связанных с ними рисках. Совершенствование процессов управления ИТ-системами производится в рамках предварительно сформулированной и утвержденной ИТ-стратегии на основе системы измеримых показателей. ИТ- стратегия связана с бизнес-стратегией предприятия, а соответствующие работы интегрированы в общий план развития предприятия. В то же время использование технологий для процессов управления ИТ направлено, прежде всего, на решение тактических ограниченных вопросов, а улучшение этих процессов происходит достаточно спонтанно. • Оптимизированный Управление ИТ рассматривается на стратегическом уровне и направлено на упреждающее решение проблем, которые могут проявиться в будущем. Обсуждение и обучение производятся с использованием передовых технологий и подходов. Процессы отточены до уровня лучших практик, доступных во внешних организациях; существует возможность сравнения показателей ИТ с показателями лучших организаций. Сама организация в целом и ее сотрудники способны быстро адаптироваться к изменению требований к ИТ. Все проблемы тщательно анализируются, и вырабатываются необходимые коррективные или предупредительные меры. Процессы управления поддержаны системой автоматизированного документооборота. Риски и преимущества, связанные с ИТ, определены, правильно сбалансированы и доступны для обсуждения по всей организации. Проводимый полный мониторинг работы ИТ-систем постоянно используется для улучшения их работы. Управление ИТ стратегически связано с управлением бизнесом, так что ИТ становится конкурентным преимуществом предприятия. Практическое использование CMM. Проект SPICE