В течение последних нескольких лет на машиностроительном предприятии «Звезда» последовательно ведется построение комплексной информационной системы. «Звезда» производит высокооборотные дизельные двигатели для судостроения и железнодорожного транспорта, а также аварийно-резервные электростанции для различных промышленных и оборонных объектов. Предприятие имеет полный цикл производства продукции — от разработки до сервиса. В производстве находится около 40 тыс. деталей и узлов, а количество технологических переделов достигает 80-100. «Основная задача информационной системы предприятия - оперировать всеми этими данными в их взаимосвязи», - говорит Павел Плавник, генеральный директор ОАО «Звезда», выступивший на секции «С широко закрытыми глазами» CIO Congress White Nights 2009. Наиболее интересные и важные моменты этого выступления, а также состоявшегося затем интервью мы предлагаем вашему вниманию.
Управление «с широко закрытыми глазами»
Сегодня одна из ключевых задач предприятия - создать комплексную информационную систему. Какие преимущества мы получим? Можно ли оценить экономический эффект от ИТ? Мы не анализируем детально экономическую эффективность каждого из блоков информационной системы предприятия, поскольку выгода, с моей точки зрения, очевидна.
Приведу небольшой пример. Раньше не требовалось никаких специальных приспособлений, чтобы контролировать обработку детали на станке, потому что скорости обработки металла были не очень высокими. Контроль велся просто визуально, и даже защитные экраны как обязательный элемент появились только к концу прошлого века. Но сегодняшние станки обрабатывают металл специальным керамическим инструментом на очень высоких скоростях. Естественно, процесс обработки уже идет в закрытой камере и при таких скоростях обработки и давлениях охлаждающих жидкостей, что визуально его проконтролировать практически невозможно. Необходимо использовать датчики и выводить информацию на специальное табло.
Так же и в масштабе всего предприятия - «с широко закрытыми глазами» сегодня просто нельзя управлять. Способов передачи информации достаточно много, но эффективность их различна. Настолько, что существует критический объем информации и необходимая скорость ее обработки, при которых не обойтись без ИТ-технологий. В сегодняшних условиях мы можем обеспечивать управляемость предприятия только при наличии ИТ-инструментов.
О планировании производства
Еще в советское время, работая начальником главного диспетчерского бюро, я занимался организацией труда. Ситуация ведь на всех заводах была одинаковая: тот не залил заготовки, тот вовремя не оформил какие‑то накладные, этот не обеспечил технологии. Непрерывный стресс плохой организации труда вызывал у меня желание выстроить систему планирования. Ведь задача предельно ясная - с учетом имеющихся нормативов по каждой детали, плана, примерно повторяющегося из месяца в месяц, и т. д. И я построил эту систему, потратив довольно много времени. Расчет велся фактически вручную - с помощью калькулятора (Excel тогда еще не было).
Задача решаемая, но, к сожалению, учитывать таким образом сегодняшний большой объем информации уже не получится. Впрочем, теперь ИТ вышли на качественно другой уровень. Появились новые продукты, которые учитывают первый негативный опыт внедрений. Они позволяют решать задачи планирования производства, и не использовать их возможности нельзя - для меня это совершенно очевидно. Иначе мы будем постоянно управлять задним числом - затыкать дыры. Нельзя управлять машиной, смотря только в зеркала заднего вида. Управление - всегда взгляд вперед.
О количественной оценке эффекта от внедрения
Чтобы абсолютизировать количественные параметры, которых мы хотели бы достичь от внедрения той или иной ИТ‑системы, нужно иметь правильные условия для их получения. Увы, не имея построенного четкого и детального учета в реальном времени, достичь нужной точности этих параметров нельзя. Без ERP‑системы было очень сложно однозначно оценить экономическую эффективность тех или иных управленческих решений.
И второй момент - это критерии оптимизации, достоверность которых тоже необходима. Например, каким должен быть уровень незавершенного производства? В советское время были отраслевые инструкции, научные расчеты, однако при нашей динамике спроса они не работают. Тогда на что опираться?
О «прививке к ИТ»
В 90‑е годы на предприятии была сделана неудачная попытка внедрить комплексную систему управления ERP-класса. Проект провалился по ряду причин: достаточно большой и сложный программный продукт и высокая динамика законодательства. В результате состыковать систему управления производством и систему бухгалтерского учета, принимая во внимание все особенности налоговой отчетности и динамику ее изменений, не получилось. Слишком различались системы учета у экономических служб, бухгалтерских и производственных.
Да, мы вложились в ИТ, не получив должного эффекта. Но в результате этот проект стал некоторой ступенькой - выросла подготовленность сотрудников к работе с такими системами. Даже если проект не выходит на этап опытной эксплуатации, мы тем не менее создаем тот задел, на базе которого можно расти дальше. В том числе и благодаря этой работе подготовленность среды, при некоторой стабилизации законодательной базы и новом уровне развития ИТ, оказалась достаточной для того, чтобы в следующих проектах выйти на уровень практического получения преимуществ от ИТ.
У нас получилась своеобразная «прививка к ИТ». Опыт провала внедрения предыдущей системы был максимально учтен. При новом внедрении задачам стыковки производственного и бухгалтерского учета мы уделяли особое внимание. И даже при этом были большие сложности. А с нуля подняться на новый уровень не всегда получается - вот почему полезны и неудачные проекты.
База ИТ промышленного предприятия
После неудачного внедрения ERP‑системы в 90‑х мы пошли по другому пути, в основе которого лежала идея о том, что для промышленного предприятия в качестве базовой должна использоваться система управления данными об изделии (PDM). Сегодня вся структура наших изделий полностью описана и с конструкторской, и с технологической стороны (нормативы по расходу материалов, трудозатраты и т. д.) в информационной системе. Это основа, которая позволяет работать с информационной структурой нашей продукции (см. рис.). Мы выбрали PDM‑систему «Лоцман», которая справляется с нашими задачами проектирования и подготовки к производству новых образцов техники.
ИТ-ландшафт предприятия
Самый дорогостоящий и одновременно центральный элемент информационной системы предприятия - ERP‑система SyteLine (см. рис). Это одна из самых тяжелых ИТ‑систем на предприятии. Ее внедрение шло непросто и заняло около двух лет, проект, что называется, выпил много крови. Но с точки зрения эффективности - сегодня это важнейший инструмент, позволяющий оперативно собирать всю информацию и комплексно планировать деятельность предприятия. Система позволяет контролировать в режиме реального времени процессы во всех подразделениях и существенно упрощает процедуру контроля производства, закупочной деятельности, планирования сроков изготовления каждого заказа в отдельности и учета затрат - в том числе и отдельно по каждому из заказов.
Вся перечисленная информация собирается достаточно легко, в автоматизированном режиме. Благодаря этому мы сегодня можем четко спланировать трудовые ресурсы, которые нам нужны под производственную программу на шесть месяцев вперед. Без ERP‑системы заранее просчитать с точностью трудовые ресурсы по каждому участку и рабочему месту было невозможно в принципе. Хотя я не очень доволен интерфейсом этого продукта - на мой взгляд, его надо дорабатывать и дорабатывать под нужды руководителей, делая максимально наглядным.
Мы также используем интересную систему «ОргМастер», которая позволяет автоматизировать управление бизнес-процессами на предприятии. Структура процессов предприятия была полностью перестроена в ходе проекта реинжиниринга несколько лет назад, и программный комплекс позволил закрепить эти процессы за счет пооперационного описания деятельности каждого подразделения вплоть до уровня рабочего места, а также непрерывно отслеживать все происходящие в процессах изменения. Чтобы решать задачи контроля исполнительской дисциплины на предприятии, повышая скорость и качество внутренних и внешних коммуникаций, мы внедрили систему электронного документооборота NauDoc. Она работает на нашем предприятии уже около пяти лет, непрерывно развивается и позволяет практически моментально проводить как обработку входящей информации, так и движение документов внутри предприятия, включая контроль исполнительской дисциплины. Она существенно ускоряет подготовку корреспонденции, организационно-распорядительных документов, договоров, причем на предприятии в любом документе (в том числе и в ходе подготовки контракта) электронная подпись приравнивается к физической.
Эта картина в дальнейшем будет дополняться новыми элементами. В частности, в ближайшее время мы будем заниматься внедрением системы для управления взаимоотношениями с покупателями, а также системы автоматизации технического обслуживания и ремонтов.
Преимущества и недостатки комплексной автоматизации
Основная предпосылка к формированию именно комплексной информационной системы - возможность формирования и актуализации значительных информационных ресурсов. Эффективность такой системы - именно в ее комплексности. Ее используют и производственники, и менеджеры управления продаж, и экономисты. Все эти функции важны, и делать повышенный акцент на какой‑либо - неправильно. Я лично работаю не столько непосредственно в системе, сколько с готовыми отчетными формами. Но у меня есть жесткое требование - чтобы ручной работы в этих отчетах не было. Естественно, у такой комплексной информационной системы есть плюсы и минусы.
| Плюсы | Минусы |
| Высвобождение «армии» учетчиковплановиковбухгалтеров | Неизбежное «подстраивание» системы управления под имеющиеся программные продукты |
| Уменьшение роли «человеческого фактора» в достоверности управленческой информации. «Прозрачность» предприятия | Необходимость тщательного выбора программного продукта |
| Получение точной информации «точно в срок» | Необходимость жесточайших административных усилий для внедрения |
| Возможность модульного наращивания в порядке и по срокам, которые определяет администрация предприятия | «Прозрачность» предприятия для контролирующих органов |
ИТ и косность мышления
Активное использование ИТ неизбежно требует подстраивать систему управления под возможности программных продуктов. За 70 лет на предприятии сложились определенные стереотипы и стандарты работы, и, как на многих машиностроительных предприятиях, есть некоторая косность и инерция старого мышления. И это одна из серьезных проблем, которую приходится преодолевать, подстраиваясь под возможности информационной системы. Но в результате мы от этого только выигрываем. Мы значительно упрощаем многие вещи, например, систему оплаты труда. До внедрения системы мы имели примерно 20 различных механизмов расчета выплат для различных групп работников. Внедряя стандартный программный продукт, который не имеет функционала такого сложного расчета заработной платы, мы отказались от старой системы начисления заработной платы и унифицировали эти процессы.
Об антикризисных мерах
В 2009 году был закончен проект автоматизации бюджетирования, который, хотя и был профинансирован до кризиса, стал хорошей антикризисной мерой. Сейчас, безусловно, повышаются требования к оперативности и уровню аналитичности информации. Наша система бюджетирования на базе программного комплекса Plan Designer как раз позволяет выполнять анализ движения денежных средств, отслеживание различных задолженностей по времени и другим факторам, многовариантный анализ перспектив развития и многое другое.
О взаимодействии ИТ-директора с руководством
Внедрение программного продукта не является инициативой ИТ-директора. В частности, на нашем предприятии основная инициатива исходила от управленцев различных направлений - например, главного бухгалтера или главного механика. А по таким комплексным системам, как ERP, основная инициатива принадлежала ключевым руководителям - мне и финансовому директору. Поэтому очень важный аспект развития ИТ на предприятии - это эффективные коммуникации ИТ-директора с менеджментом разных категорий. Было бы очень полезно своевременно информировать руководителей о возможностях современных программных продуктов, обращать людей в свою веру. Это основной совет, который мне хотелось дать ИТ-директорам, - больше контактировать с сотрудниками, которые непосредственно используют ИТ‑системы.
Причем это очень важно не только во время старта проекта и выбора продукта, но и на этапе его эксплуатации. Поскольку наличие уникальных ИТ‑систем не гарантирует эффективного их использования, не все с большим удовольствием используют эти продукты. Это одна из серьезных проблем. И авторитет ИТ-директора надо максимально использовать для включения информационных технологий в реальную работу предприятия.
В чем проблема всех без исключения российских компаний? У бизнеса есть свое понимание происходящего, свои требования и задачи, однако их очень сложно переложить на язык конкретных ИТ-действий, и не всегда эти требования доходят до ИТ в понятном виде.
Вторая традиционная проблема - унаследованные ИТ. В прошлые годы было произведено много хаотичных закупок и внедрений, что создает большую сложность ИТ-ландшафта. У любого ИТ-руководителя, пришедшего в компанию, очень много времени уходит на понимание сложившейся ситуации. С другой стороны, бизнес инвестирует в ИТ деньги и хочет видеть, куда они уходят, на какие проекты и инициативы, и как это продвигает компанию к стратегическим целям.
В России направление корпоративной архитектуры пока не развито. Компаниями весьма востребована разработка архитектур конкретных решений, а вот увязкой компонентов архитектуры внутри организации всерьез никто не занимается. В лучшем случае с этой целью используются электронные таблицы, где информация хранится в неформализованном виде, а при уходе менеджера из компании - знания уходят вместе с ним.
Самое главное последствие такого подхода - неоптимальное расходование средств на ИТ, иногда даже их прямая растрата. Именно поэтому за рубежом компании все чаще демонстрируют стратегический подход к управлению ИТ, и вектор все больше склоняется в сторону упорядочения и стандартизации корпоративных ИТ-ландшафтов.
Слова - в действия
Проблема очевидна: необходимо связать бизнес с ИТ, выстроить мостик между ними, обеспечив прозрачность. Стратегию необходимо переложить в требования и действия, которые нужно донести до людей. Каждое подразделение должно понимать суть работ и общее направление развития ИТ.Для решения этой задачи предназначена система HPE Enterprise Maps. Что немаловажно, это собственная разработка компании, а не приобретенное решение, что в последнее время стало редкостью. Это хорошо: HPE как поставщик систем сам дошел до понимания того, что на рынке нужно и необходимо, и выступил с инициативой разработки такого продукта. Являясь собственной разработкой, Enterprise Maps без проблем взаимодействует с другими системами HPE и обогащается данными из них, превращаясь в целостное, мощное решение.
Дабы не изобретать велосипед, в Enterprise Maps применяется методология TOGAF, понятная архитекторам и показывающая, как подходить к управлению корпоративной архитектурой. В качестве языка описания взаимодействия элементов архитектуры друг с другом используется нотация ArchiMate 2.0.
Основные задачи разработанной системы - уменьшить риски и запутанность, связанные с ИТ, обеспечить соответствие ИТ-стратегии. Крайне важно уметь «красивые» слова перекладывать в конкретные действия. Кроме того, осмысленное управление «зоопарком» существующих систем становится нетривиальным занятием: на рынке очень много поставщиков со своими политиками лицензирования, обновления продуктов и вывода старых решений из оборота.
Практически в любой компании можно найти ПО, у которого оплачивается поддержка, хотя она реально не нужна или - более того - система уже снята с поддержки. Бывает и наоборот: компания планирует построение новой системы, не отдавая себе отчет в том, что используемая платформа сильно устарела.
Для ИТ и бизнеса
Кому это может быть интересно? Если в компании существует такая позиция, как корпоративный архитектор, то он станет главным заинтересованным лицом.Обычно для описания архитектуры используют программы-«рисовалки» - например, Microsoft Visio. Важно отметить, что Enterprise Maps - это не рисование, а создание моделей, связанных с реальным миром, и во время их разработки будет отслеживаться соблюдение различных политик. Невозможно создать объект, оторванный от реальности.
Архитекторы - аудитория, понимающая преимущества системы и способная по достоинству оценить её возможности. Однако, к сожалению, они чаще всего не распоряжаются бюджетами, и решения будут приниматься выше.
Следующей важной группой пользователей являются финансовые руководители и ИТ-директора. У них задачи другие. Скажем, финансовый директор может не слишком сильно понимать, что происходит в ИТ, но ему важно видеть, куда идут инвестиции и насколько приоритетна эта область с точки зрения стратегии. Он получит информацию об этом не в виде отредактированного сотрудниками отчета, а с помощью реального среза информации. Для ИТ-директора важны прозрачность деятельности ИТ-департамента и дополнительное обоснование своих решений перед топ-менеджментом.
Конечно, в решениях такого класса заинтересован большой бизнес, достигший определенной зрелости, - люди, которые поняли, что надо наводить в хозяйстве порядок. Что очень важно, Enterprise Maps, в отличие от более тяжелых решений, требующих фундаментального подхода, предлагает путь «быстрых побед»: оперативно внедрить отдельный сценарий, чтобы зарекомендовать себя, а затем постепенно наращивать мощь решения.
Например, в системе «зашит» сценарий «Пять шагов для выноса приложения в облако». Иметь такие готовые сценарии очень важно для реализации быстрых проектов, показывающих бизнесу пользу решения.
Не только отчетность
Можно выделить три типичных направления, которые покрывает Enterprise Maps. Первое - объединить имеющиеся данные (модели архитектуры, стратегии бизнеса) в едином хранилище, где все элементы связаны с корпоративной архитектурой, обозначить людей, ответственных за срезы информации, настроить синхронизацию с различными источниками данных.Во-вторых, видя текущую ситуацию, можно выстроить план перехода к целевому состоянию, определив с помощью Gap-анализа недостающие элементы. В этом заключается ключевое отличие решения от баз данных управления конфигурациями (UCMDB), отражающих только текущую ситуацию и только на инфраструктурном уровне. Третье важное направление - стандартизация подхода к ИТ-активам, системам и функциям.
На выходе системы компания получает срезы информации для различных пользователей. Каждый из них будет видеть ту информацию, в которой заинтересован. С помощью Enterprise Maps можно отвечать на самые различные вопросы: например, можно будет узнать, во сколько обходится содержание того или иного приложения, соответствуют ли инвестиции стратегии, куда уходят средства, что возможно сделать с помощью выделенного бюджета.
Обычно, увидев возможности Enterprise Maps, многие спрашивают: так это система отчетности? Да, сходство большое. Но решение не просто отвечает за представление данных в красивом графическом виде, но и становится главным рабочим инструментом архитектора - средством создания и сопровождения моделей архитектуры предприятия.
Важно, что внутри системы можно заложить политики развития архитектуры (как инфраструктурной части, так и приложений), которые будут отслеживаться. Запрещенные действия совершить не получится, и дальнейшее соответствие правилам будет перепроверяться. Таким образом, архитектор не просто «рисует картинки», а вполне обдуманно подходит к решению задач.
Источники данных
Для того чтобы система была работоспособной, её надо наполнить данными. Это легко можно сделать с помощью таблиц Excel и файлов, и этого хватает для большинства заказчиков - именно в таком виде обычно хранится информация о корпоративной архитектуре. У более продвинутых заказчиков есть системы UCMDB, которые также становятся ценным источником данных.Еще один важный источник - система управления портфелем проектов. Отсюда берутся цели, программы, проекты. На основании этих данных можно показывать место реализуемых проектов в общей стратегии.
Наконец, для наполнения систем не обойтись без средств моделирования - например, Sparx Enterprise Architect, одной из наиболее популярных систем в силу своей дешевизны. Более того, в ряде случаев использование таких специализированных средств предпочтительно. Если разрабатывается новая система, становящаяся крупным элементом архитектуры, лучше взять средства проектирования, предназначенные для этого и знакомые пользователям, а затем построенные модели загрузить в Enterprise Maps, где они будут связаны с текущими системами, инфраструктурой, планами и проектной деятельностью.
Объективная картина
Важной частью системы являются встроенные отчеты - срезы информации, становящиеся ценным источником знаний при принятии решений о развитии ИТ. Среди них можно выделить несколько ключевых.Одним из них является отчет «Бизнес-возможности портфеля приложений». Основываясь на его данных, можно сказать, куда компания должна инвестировать в соответствии со своей стратегией, выделив стратегически важные решения, Или наоборот - определить кандидатов на переход в облако. Следующим шагом является определение критичных бизнес-приложений, поддерживающих ключевые процессы и потому требующих особого отношения.
Отчет «Стратегические инвестиции» позволяет увидеть разрывы между реальными инвестициями и приоритетами бизнеса. Например, на базе финансовой информации из системы управления портфелем проектов можно определить чрезмерные инвестиции в неприоритетные направления. Это дает финансовую прозрачность, которую так хочет видеть бизнес. Обзор стоимости приложений также дает пищу для размышлений относительно их бизнес-ценности и реальных затрат на них.
«Использование платформ» - отчет, который также может быть очень полезен. Он позволяет понять, например, что в трети приложений используется неподдерживаемая платформа, и если планируется внедрение новой системы, то следует задуматься.
Одна из важнейших возможностей - создание «дерева зависимостей», показывающего взаимосвязь между конкретными элементами инфраструктуры и бизнес-сервисами. Нередки ситуации, когда работа значимой для бизнеса системы поддерживается одним сервером, что снижает её отказоустойчивость, или наоборот - некритичное приложение работает на неоправданно дорогом оборудовании.
Средство наведения порядка
Среди наиболее интересующихся корпоративной архитектурой компаний можно выделить довольно зрелые финансовые организации. Причины очевидны: им постоянно приходится быть «на передовой ИТ», захватывая новые рынки, что находит отражение в ИТ-архитектуре. Им гораздо чаще нужна прозрачность, в том числе в процессе достижения целей. Наконец, в финансовой сфере крайне высока конкуренция, и крупные ошибки в ИТ могут дорого обойтись.Не стоит думать, что системы управления корпоративной архитектурой - решения исключительно для гигантов. Если удастся показать бизнесу, что существуют платформы, за которые уже давно можно не платить, или бизнес-требования, которым уделяется недостаточно внимания, результат может быть очень впечатляющим даже при небольших размерах компании.
Тем не менее разумное ограничение по размеру компании все же существует. Минимальная закупка - 10 лицензий, то есть в организации должно быть минимум 10 человек, кому это интересно. А несколько архитекторов - это уже достаточно большая организация.
Но главное - компания должна быть готова, накупив в прошлые годы массу оборудования и приложений, навести порядок в своем ИТ-хозяйстве. Таких пока немного.
Если вы зайдете в офис средней или крупной организации, поймаете в коридоре сотрудника и спросите у него: «Чем в вашей компании занимаются ИТ-архитекторы», то вряд ли услышите в ответ: «Как чем? Они моделируют структуру и поведение информационных систем; с различных точек зрений отображают их текущее и целевое состояние, формулируют фундаментальные принципы организации корпоративной информационной системы для принятия ключевых решений…». Вероятность такого события существуют, но она совсем небольшая. Если же ваш собеседник произнесет такие или похожие слова, то значит случилось маловероятное событие и вы поймали в коридоре именно ИТ-архитектора. Скорее всего этого не произойдет. Ваш собеседник на некоторое время задумается, но возможно вспомнит, что есть в ИТ такой парень, которого называют архитектором. И еще, что он рисует какую-то большую не очень внятную картинку и с умным видом произносит загадочные слова. Впрочем, айтишники они все такие…
Мы расширяем линейку курсов по архитектуре информационных систем мастер-классом «Разработка карты ИТ-ландшафта». За один полный учебный день мы разберемся что такое landscape map и поучимся рисовать ту самую не очень внятную картинку . В определенном смысле карте ИТ-ландшафта немного не повезло. Несмотря на то, что практика рисования карт, визуализирующих все приложения организации на одном листе, достаточно распространена, руководств по этому виду деятельности крайне мало. Карта ИТ-ландшафта попала во вторую версию стандарта моделирования корпоративной архитектуры archimate, но в третьей версии куда-то исчезла. Да и во второй версии archimate описание карты ИТ-ландшафта крайне лаконично. На самом деле, пример, приведенной на картинке выше, сопровождает вполне внятная история развития приложений компании ArchiSurance, вызванная чередой слияний и трансформаций бизнеса. Но эта история не приведена в стандарте или на сайте The Open Group, а передается из уст в уста. Есть серия работ, раскрывающих подходы к созданию landscape map более подробно, таких как, например: «Landscape Maps for Enterprise Architectures» L. van der Torre и др. или «An Approach to Managing Application Landscape» Sameer Paradkar, Jay Kulkarni, но они мало кому известны. Пожалуй, единственный источник, известный большинству архитекторов предприятия источник, затрагивающий тему одной картинки это знаменитая “Enterprise architecture as Strategy” Jeanne W. Ross.
В тоже время landscape map view это крайне содержательный инструмент, визуализирующий не столько объекты, а в большей степени отношения между ними. Приложения в этом представлении выступают в качестве ассоциирующих классов , объединяющих, например, функции и направления деятельности. Аналогичным способом можно визуализировать ассоциации и между другими типами объектов. В принципе, строчки и столбцы landscape map можно выбирать произвольно. По сути ландшафтная карта - это инструмент создания наиболее интересных срезов паутины сущностей и отношений между ними.
Хорошую карту сделать не просто. Мы начнем с того, что перестанем смотреть на приложения, как на статические объекты, а представим их в виде акторов — субъектов, осуществляющих один из этапов деятельности в цепочке обработки данных (или потоке создания ценности). Такой подход позволит нам выстроить приложения в необходимой последовательности. Не менее интересной задачей станет взаимное расположение цепочек друг относительно друга. Есть еще много подходов, позволяющих буквально нашпиговать ландшафтную карту тем или иным содержанием. Надеюсь об основных из них мы успеем поговорить.
Более формальное описание мероприятия и регистрация на сайте IT Expert: https://www.itexpert.ru/rus/services/training/moscow/detail.php?ID=7172 анонс на фейсбук.
14-15 апреля в Подмосковье компания «Инфосистемы Джет» провела для заказчиков ежегодный семинар. Тема мероприятия - «Современный ИТ-ландшафт: новая реальность».
«Мир корпоративных ИТ динамично меняется. С одной стороны, на него влияют политическая и экономическая ситуация, а также требования бизнеса, которому необходима возможность быстрого изменения ИТ-ландшафта под текущие задачи. С другой стороны, меняются сами ИТ-технологии, подходы к построению и обслуживанию ИТ-ландшафта. Задача нашего семинара - дать заказчикам ориентиры в сложном и быстро меняющемся мире ИТ. У нас, как интегратора, есть опыт как тестирования и пилотной эксплуатации технологий и ИТ-решений разных вендоров, так и реальных проектов для конкретных заказчиков. Мы знакомим заказчиков с этим опытом, обсуждаем практические вопросы, помогаем разобраться в нюансах тех или иных подходов. В то же время мы сами получаем обратную связь и мнение заказчиков, а также предоставляем им площадку для обмена опытом между собой», - рассказывает Андрей Шапошников, заместитель директора Технического центра компании «Инфосистемы Джет» .
Формат мероприятия был сделан максимально интерактивным - участники имели возможность задать вопросы и высказать свое мнение как в ходе докладов, так и в рамках специально организованных круглых столов.
Открыла семинар панельная дискуссия не тему «Как использовать новые технологии в традиционном бизнесе».
Как отмечалось в ходе дискуссии, ИТ-специалистам предприятий сегодня приходится работать по новым правилам, ориентируясь не на технологии как таковые, а на достижение определенных бизнес-целей. Подход к развитию ИТ стал более прагматичным. Все больше заказчиков выбирают решения, позволяющие сделать ИТ-инфраструктуру проще, гибче и вместе с тем надежнее. Например, применяют для ее построения стандартные серверы x86 и грид-архитектуру. Меняется парадигма построения прикладного ландшафта, становятся востребованными решения, которые обеспечивают более высокую доступность ПО и отсутствие единой точки отказа.
Переход от «монолитных» приложений к распределенным - одна из современных тенденций. Сегодня имеет смысл говорить не о наборе самостоятельных приложений, каждое из которых решает конкретную задачу, а об ИТ-ландшафте, где в виртуальной инфраструктуре развернут постоянно растущий и меняющийся набор сервисов. В таком ландшафте каждая новая бизнес-задача реализуется не путем написания очередного приложения, а путем оркестрации существующих сервисов - из них собирается та логика, которая в данный момент необходима бизнесу.
Это заставляет разработчиков менять подход к созданию приложений - приложения изначально должны быть готовы для предоставления в качестве сервисов из частного или публичного облака. О том, как этого добиться, было рассказано в рамках докладов, посвященных облачному программированию и контейнеризации приложений.
Нарастает тенденция внедрения в ИТ-системы элементов аналитики, позволяющих собирать статистику использования сервиса бизнес-пользователями или конечными потребителями. Это позволяет прогнозировать динамику спроса и своевременно адаптировать ИТ-сервисы под меняющиеся пользовательские запросы.
Для предприятий, уже построивших собственные ИТ-инфраструктуры, актуален вопрос сохранения инвестиций, иными словами, извлечения максимальной пользы из уже существующего оборудования. Решение вопроса - виртуализация, и уже не только серверов (что на сегодня является «нормой жизни»), но и систем хранения и сетей, а в дальнейшем - переход к программно определяемым инфраструктурам.
Технологии программно определяемых СХД (SDS) и сетей (SDN) пока еще молоды и не всегда понятны заказчикам. Особенно SDN, где пока не существует единого стандартизованного подхода, и каждый вендор предлагает свой вариант реализации. Эксперты компании «Инфосистемы Джет» протестировали множество решений от разных производителей. Некоторые из них были представлены на стендах вендоров, где участники семинара могли подробно познакомиться с особенностями их работы.
На рынке СХД одна из наиболее обсуждаемых тем - системы хранения All-Flash. Ей был посвящен один из круглых столов. По соотношению производительности и емкости All-Flash системы значительно превосходят обычные СХД, энергопотребление flash-памяти ниже, чем у обычных дисков. Кроме того, современные решения имеют встроенные алгоритмы уменьшения объема данных, позволяющие сэкономить пространство хранения. Благодаря этому All-Flash системы становятся востребованы не только для ускорения отклика отдельных приложений, но и в качестве основного хранилища данных.
Уделив основное внимание новым технологиям и подходам, организаторы мероприятия не оставили без внимания и традиционные решения на платформе RISC, которые давно используются многими заказчиками. На специальной секции участники могли узнать о возможностях решений SAP HANA on IBM Power, новых серверных платформ Oracle SPARC T7 и M7, новых решений для защиты данных Veritas.
Были времена, когда информационного ландшафта не было. Или его просто предпочитали не замечать? Информационные системы отличались необыкновенным высокомерием и царили в стерильном безвоздушном пространстве. Становясь все сложнее и сложнее, они стали задумываться о своей архитектуре - как обеспечить себя, любимых, такими привлекательными качествами, как выносливость и работоспособность. Но по-прежнему отличались непростительным себялюбием.
Каждый проект внедрения автоматизированных систем (АС) старался поменьше обращать внимания на то, чем уже обладало предприятие в области ИТ (на его текущий ИТ-ландшафт), что было вполне оправданно с коммерческой точки зрения. Понятие ландшафта применительно к ИТ одной из первых использовала компания SAP, когда на сложном пути самопознания, направленном на получение конкурентных преимуществ и прибыли, обнаружила, что, оказывается, даже она не покрывает всех потребностей современного предприятия в автоматизации. Оглянувшись вокруг, она нашла множество систем, системок и программ, отказаться от которых предприятие не хочет или не может. Известные приемы переноса, как раньше, данных из одной системы в другую, печатая ли их из одной системы и вводя на клавиатуре в другую, выполняя копирование или записывая в Excel и выгружая оттуда, уже давно показали свою неэффективность. Более того, они опасны для качества информации. Все те оперативность и достоверность, которых удавалось добиться путем внедрения отнюдь не самого дешевого ПО с помощью не самых простых и малозатратных проектов, рассыпались при подобного рода «интеграции» или, скорее, «дезинтеграции».
Сначала принялись роптать пользователи, за ними - бизнес-заказчики. Пользователи - из-за механической и бессмысленной работы переносчиков информации, заказчики - из-за отсутствия реальных преимуществ, которые сулили поставщики тяжелых систем и внедряющие эти решения компании. Тут-то и наступила эра «ландшафтного дизайна ИТ». Оказалось, что вокруг имеется множество АС, оборудования, средств связи, живых людей с их привычками и опытом, а также корпоративных стандартов, которые необходимо учитывать и с которыми предстоит уживаться. Иначе говоря, светлое здание АС приходится строить в реальном, а не в абстрактном мире. И тут небоскреб на дачном участке становится по меньшей мере неуместен, как и бытовка в центре города. Конечно, кусты можно вырыть, лужу засыпать, небольшую возвышенность заровнять, а здание разрушить. Но чем более значительны элементы информационного ландшафта, тем сложнее их изменить в угоду новому архитектурному сооружению. И по меньшей мере эти усилия и соответствующие затраты необходимо учитывать при анализе проекта.
Ландшафт и архитектура
Итак, при формировании архитектуры АС надо учитывать окружающий ландшафт, однако возникает вопрос: «А зачем понадобилось вводить понятие ландшафта, когда уже есть понятие архитектуры предприятия (Enterprise Architecture)?» Вокруг нее уже сложилась система представлений, стандартов и методик. Трудно сказать, чем руководствовались авторы из SAP, но можно предположить, что понятие ландшафта понадобилось им, чтобы отделить возводимую постройку новой системы от той данности, которая уже присутствует на предприятии. Есть и еще один аспект. Если архитектура предполагает определенную открытость, понятность, формализацию, то ландшафт может нести в себе больше тайн и поддаваться живописанию с неопределенной степенью достоверности. А ведь все то, что называется унаследованными системами, как раз практически всегда плохо или совсем не документировано. Поэтому, когда к ландшафту применяются методы описания архитектуры предприятия, мы должны быть готовы к множеству белых и серых пятен. Заполнение этих пятен - там, где это необходимо, представляет собой отдельную науку или, скорее, искусство. Достаточно часто невозможность формализации заставляет компании отказываться от существующих элементов ландшафта и ввергает их в затратные проекты, имеющие высокую степень риска. Поэтому, как и в природе, информационный ландшафт может таить в себе угрозы и неприятности. Однако, освоив ландшафтный дизайн, недостатки можно превратить в преимущества, умело встраивая сооружение в окружающую «природу», искусно используя существующие средства ИТ.
Ландшафт современного предприятия достаточно сильно зависит от типа предприятия (см. табл. 1).
| Тип классификации | Влияние на ландшафт | Особенности ландшафта |
|---|---|---|
| Отрасль | Для банков особую роль играют АБС, для телекома - системы биллинга, для машиностроения, судостроения, авиастроения - CAD/CAM/PDM, для производственных предприятий - АСУТП и MES, для продающих компаний - системы Sales Force Automation и CRM. | В отдельных отраслях ландшафт выстраивается вокруг центральной, наиболее значимой для предприятия АС. |
| Территориальное устройство | Для распределенных, сильно централизованных компаний необходимы централизованные АС, поддерживающие распределенную архитектуру и устойчивые к сетевым сбоям. Кроме того, это налагает требования на организацию сети и весь ландшафт. | Для территориально распределенных компаний с сильной централизацией характерно высокое качество средств связи и надежность ПО к сетевым сбоям. |
| Тип собственности | Государственные предприятия активно потребляют системы документооборота, коммерческие - аналитические системы. | Тип собственности определяет требования к документообороту и средствам автоматизации финансового управления. |
| Размер | Для крупных компаний важны производительность и масштабируемость системы, ее надежность. Для малых - простота установки, настройки и обслуживания. | Требования к компонентам архитектуры предприятия различны, поэтому вид ландшафта существенно различается. |
Практически для всех современных компаний характерен пестрый информационный ландшафт, и то, что называют наследуемыми системами, играет в нем заметную роль. Уже давно никто не предлагает вырубить все это под корень и полностью преобразовать в едином проекте. Поэтому не только любое внедрение, но и большинство изменений на любом из архитектурных слоев требуют анализа того, как эти изменения повлияют на весь ландшафт предприятия. К сожалению, качество управления изменениями в большинстве случаев оставляет желать лучшего. Мало кто задумывается о ландшафте. Хорошо, если ограничиваются хотя бы прилежащими «кустами», а то и вовсе планируют внедрение АС, как в старые добрые времена - без учета существующего информационного ландшафта.
Классификация компонентов ландшафта
Давайте попробуем взглянуть (табл. 2) на компоненты информационного ландшафта, на все эти кусты, деревья, ягодки и цветочки, и на то, каким образом они сочетаются друг с другом.
| Тип элемента ландшафта | Основные характеристики | Способы интеграции |
|---|---|---|
| Большие корпоративные системы (ERP, CRM, ...) |
Широкий спектр функциональности
Грамотная архитектура Методика внедрения Хорошая документация Хорошо развитые API и продуманная технология доработок |
Продуманные методики интеграции, интерфейсы, адаптеры, описанные на XML
ESB, серверы приложений J2EE, .NET, CORBA, XML, EDI |
| Готовые системы узкой специализации (best of bread) (документооборот, управление проектами, системы бухгалтерского учета …) | Системы, занимающие одно из лидирующих мест в своем сегменте. Обычно предлагают лучшую функциональность в своей области, чем большие системы. | Возможности интеграции не столь многообразны, как у больших систем, но выбор технологий обычно тот же. |
| Функциональные платформы (BPM, поддержка сервисов, …) | Системы, предлагающие удобные средства сборки АС в выбранной функциональной области. Такая сборка большей частью не предполагает кодирования, хотя и эти системы всегда имеют API. Обычно предлагаются также готовые решения на этих платформах, которые можно дорабатывать. | Способы интеграции определяются технологией, на которой основана платформа. Чаще всего встречаются платформы на J2EE и.NET. |
| Программные платформы - среды разработки (Eсlipse, Visual Studio, NetBean) | Программные платформы предлагают разработчикам удобные средства сборки приложений широкой функциональности и обычно не несут в себе элементы, ориентированные на конкретную функциональную область. Многие платформы предлагают средства визуальной разработки, которые позволяют частично создавать приложения без кодирования | Средства интеграции определяются используемой технологией, в данном случае языком программирования |
| Заказные разработки | Обычно заказные разработки хоть как-то документированы | Средства интеграции зависят от того, что, собственно, заказывали, поэтому если на разработку есть какие-то планы по интеграции, то лучше сразу включить соответствующие требования в ТЗ. |
| Собственные разработки | Собственные разработки также могут быть созданы на платформе. Обычно они плохо или совсем не документированы и зачастую представляют собой черный ящик, не поддающийся изменениям. | Самые сложные для интеграции элементы ландшафта |
В общем случае ни один из элементов табл. 2 ничуть не лучше и не хуже другого - все зависит от конкретной компании и ситуации. В частности, трудно поддающиеся интеграции собственные программы при хорошо поставленном в компании процессе разработки ПО могут оказаться более пригодными для сочетания с другими компонентами, чем все прочие элементы. В пользу последнего вывода можно привести пример крупнейшего Японского телекоммуникационного оператора связи - компании Docomo. Все ПО в этой компании разрабатывается самостоятельно, для чего в Docomo держат немалый штат ИТ-специалистов. Такой подход они объясняют просто: «Для нас гибкость является важнейшим конкурентным преимуществом. А для гибкости бизнеса необходима гибкость наших АС. Поэтому мы готовы оплачивать несколько сотен разработчиков, вкладывать силы и средства в их обучение и мотивацию, но иметь за это “все изменения в своих руках”». Насколько можно судить, многие японские компании придерживаются такого подхода, что, видимо, наилучшим образом соответствует японскому бизнес-чуду.
Российские компании, наоборот, находятся сейчас на этапе перехода от собственных разработок к аутсорсингу. Многие руководители считают, что в этом случае они смогут полностью оказаться от управления процессом создания АС и излечатся от мучительной головной боли. Их иллюзия состоит в том, что всеми остальными элементами, кроме собственных разработок, можно не управлять и созданные аутсорсерами системы, посаженные на почву родного предприятия, окажутся вполне сочетаемыми друг с другом и с окружающим ландшафтом. Уж сколько раз твердили миру: при выборе любого компонента требование его сочетаемости должно стать одним из самых главных - а воз, увы, и ныне там. Понятно, чтобы выдвинуть такое требование, надо знать, что спрашивать, - информационный ландшафт должен быть описан хоть в каком-то достоверном виде. А у кого это есть? Вот и появляются на свет нежизнеспособные уродцы - АС, которые не приживаются и прижиться не могут, и чахнут в условиях корпоративного ландшафта под возмущенные причитания тех, кто пытался их привить.
Инструменты объединения элементов ландшафта
Есть две «новости»: хорошая и плохая. Хорошая в том, что современные ИТ позволяют интегрировать что угодно с чем угодно. Это вопрос ресурсов (сил и денег), надежности того, что получится в результате, и усилий, которых потребуют сопровождение и поддержка интегрированного решения. При этом последний вопрос явно не изучен. Когда говорят о природном ландшафте, то помнят, что без соответствующего ухода он очень скоро превратится в дикую чащобу. Когда говорят об информационном ландшафте, то считают, что важно его один раз обиходить, а дальше все будет хорошо. Как и многие заблуждения, это кроется в глубинах подсознания, поэтому с ним трудно бороться.
Плохая новость в том, что любое интегрированное решение на порядок сложнее, труднее в обслуживании и развитии, дороже и при этом намного хуже продаваемого бизнесу. Последнее - весьма существенно. С этой проблемой сталкиваются как руководители ИТ, так и интеграторы и консультанты. Ведь эту самую интеграцию не покажешь и не внедришь отдельно от того, что интегрируется. А объяснить, что теперь информация будет иного качества, довольно сложно, так как понятие качества информации у нас совсем не развито, к сожалению.
Вот и идут интеграционные проекты пристёжкой к проектам внедрения, их финансируют по остаточному принципу и делают «на живую нитку», подразумевая, что потом, как-нибудь, когда время и бюджет появится, сделаем все как надо. Однако нет ничего более постоянного, чем временное. Поэтому недоделанность интеграции аукается предприятию еще многие годы, не позволяя ни получить обещанные выгоды, ни грамотно реализовать необходимые изменения. В качестве иллюстрации можно привести рассуждения одного менеджера от ИТ, который уговаривал руководство внедрить хотя бы интеграцию и таким образом показать успех проекта: «Ну а связать-то мы две системы можем? Ах, уже что-то работает! Ну и давайте это и покажем!». Очевидно, надо было показать только виртуальный мост между двумя, пока еще не работающими, системами.
Системы объединения элементов информационного ландшафта можно условно разделить на две группы: ленточные и зонтичные.
Ленточные обычно строятся на основе шины ESB, к которой на «присосках» - стандартизованных интерфейсах - крепятся отдельные АС, через шину взаимодействующие друг с другом. Эти системы выросли из технологии CORBA и систем обмена сообщениями.
Зонтичные, которые также часто основаны на ESB, осуществляют доступ к разрозненным системам информационного ландшафта, накрывая их собой, как зонтиком. В простейшем виде - это корпоративные порталы, предоставляющие доступ к разнообразным АС организации. Активно завоевывающие сегодня популярность системы ВРМ относятся к зонтичному типу.
Что ленточные, что зонтичные интегрированные системы чаще всего требуют переработки интегрируемых АС, если только последние не обладали большим количеством заранее предопределенных адаптеров или интерфейсов. Поскольку в интегрированном ландшафтном мире это приобретает все большее значение, многие производители стараются обеспечить свои детища набором удобных и надежных интеграционных свойств. Они не без основания полагают, что это является одним из важных конкурентных преимуществ. Хотелось бы, чтобы потребители, в свою очередь, научились оценивать эти усилия.
С другой стороны, производители заботятся только о своих «кустах и деревьях» информационного ландшафта. Вряд ли от них можно требовать, чтобы они выступали садовниками всего информационного ландшафта предприятия - это поле для системных интеграторов, как по названию, так и по сути. Однако пока отечественные интеграторы не стремятся взять на себя эту почетную, но весьма непростую роль. В ситуации, когда облака грозятся захватить большие куски ИТ-рынка, системные интеграторы должны ринуться в эту пока еще полупустую область бизнеса.
Если Сеть объединяет людей в разных уголках мира, то она же прекрасно подходит для объединения компаний, для выстраивания того, что называется Supply Chain - цепочки поставщиков для организации взаимодействия поставщиков и потребителей, для совместной работы и краудсорсинга (привлечения к производству и продаже «толпы» добровольных сотрудников). Все это предполагает совсем другой информационный ландшафт, по сравнению с тем, о котором мы говорили ранее. Возможно, даже термин «ландшафт» тут не совсем уместен, а более подойдет «информационный мир» или «бизнес-интернет». Очевидно, что требования к осуществляющим интеграцию инструментам будут только расти.
Однако пока взаимодействие компаний, что удивительно, все еще нередко основывается на древней EDI, когда одна АС положила файл, а вторая его забрала. Другое дело, что теперь эти файлы имеют формат XML, в частности, именно на EDI обычно построено взаимодействие крупнейших автомобильных концернов с поставщиками комплектующих. Кстати, тем, кто еще не осознал, что интеграция уже перестала быть чем-то, от чего можно легко отмахнуться, следует знать - без предоставления оперативной информации о прохождении заказа, без интеграции с АС, используемой автогигантом, компания не будет даже рассматриваться как поставщик автокомпонентов.
Интеграция, вопросы создания и ухода за информационным ландшафтом все более захватывают банки и телеком, производственные и розничные компании. В любом случае будущее связано с таким информационным ландшафтом, который позволит легко встраивать в себя новые элементы, убирать и заменять существующие и относиться к ИТ предприятия как к единому целому.
Марина Аншина ([email protected]) - председатель комитета по стандартам Российского союза ИТ-директоров (Москва).
