ИТ: легче
на поворотах

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

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

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

Из компаний, действующих по принципу «сначала дороги — потом дома», больше других преуспел японский банк Shinsei. Всего за год он спроектировал и развернул новую корпоративную систему, что обошлось ему лишь в $55 млн: установка и адаптация готового пакета ПО потребовала бы в четыре раза больше времени и в десять раз больше денег. Благодаря особой гибкости новая система поддерживает не только традиционные направления работы банка, но и новые его проекты: обслуживание физических лиц, потребительское кредитование, продвижение индийских ПИФов в Японии.

Создавая, отлаживая и внедряя новую систему, банк ставил перед собой следующие задачи: не просто увязать друг с другом бизнес- и ИТ-стратегии, а слить их воедино; применять самые простые программно-технические решения; сделать систему по-настоящему модульной; не навязывать ее сотрудникам, а позволить им определять, как и в каком направлении ее совершенствовать. Какие-то из этих принципов в целом давно известны, а какие-то — переворачивают общепризнанные представления с ног на голову И тем не менее их стоит взять на вооружение другим компаниям.

Герой поневоле

Shinsei появился на горизонте в 1998 году, когда обанкротился Банк долгосрочного кредитования (правительство Японии основало его после Второй мировой войны, чтобы финансировать восстановление промышленности страны). К моменту банкротства общий объем проблемных кредитов банка составлял $40 млрд. Банк национализировали, а в 2000 году продали американскому фонду прямых инвестиций Ripplewood Holdings, после чего он стал называться Shinsei (возрождение). Руководство Ripplewood уговорило бывшего главу Citibank Japan Масамото Ясиро, тогда уже вышедшего на пенсию, возглавить Shinsei. Ясиро не только модернизировал работу банка с предприятиями, но и коренным образом изменил систему банковского ритейла, создав уникальные для Японии высококачественные, но недорогие и простые банковские продукты. Такая стратегия обязывала Shinsei научиться оказывать услуги, редкие в то время на японском рынке. Именно тогда появились круглосуточные банкоматы, работающие без комиссии, интернет-банкинг с интерфейсом на японском и английском, оперативное обслуживание с синхронизацией баз данных в режиме реального времени (информация о счетах клиентов обновляется сразу после операции), обмен валюты в интернете.

Ясиро понимал: чтобы занять выгодные позиции в рознице, нужно торопиться. Однако ИТ-системы Shinsei к тому моменту устарели и не соответствовали задачам бизнеса. Ясиро пригласил на должность ИТ-директора своего бывшего коллегу Дхананджая (Джея) Двиведи, в прошлом начальника ИТ-отдела Citibank Japan, и тот сразу же собрал вокруг себя талантливых сотрудников, многие из которых работали с ним раньше.

Инвестиционные ресурсы банка были ограничены, поэтому, когда Ясиро поручил Двиведи изменить ИТ-систему, он просил сделать это «побыстрее и подешевле». Что понадобится банку для новых проектов, Ясиро и Двиведи представляли себе весьма смутно — и сами понимали это. Значит, решили они, нужно создать систему, которая бы развивалась по мере роста предприятия и легко адаптировалась к новым условиям.

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

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

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

Хотя банк до сих пор еще не получает большой прибыли от обслуживания физлиц (из-за расходов, связанных с организацией бизнеса, и из-за не вполне благоприятного экономического и правового климата в Японии), отчасти благодаря новой корпоративной ИТ-системе Shinsei очень быстро стал важным игроком японского рынка ритейла. На 30 июня 2007 года клиентами банка числилось более 2 млн физических лиц по сравнению с менее чем 50 тысячами в 2001 году, когда его клиентура состояла исключительно из богатых. Сингапурский журнал The Asian Banker в 2004 и 2005 годах называл Shinsei лучшим розничным банком Японии, а одна из самых влиятельных японских деловых газет Nihon Keizai Shimbun в 2004, 2005 и 2006 годах — лучшим из всех японских банков по качеству обслуживания.

Познакомимся ближе с методом строительства ИТ «под заказ», который избрал Shinsei.

Сплавить воедино бизнес- и ИТ-стратегии

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

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

Ситуация еще более запутывается, когда компания переходит на новый универсальный пакет прикладного ПО: как правило, бизнес приходится подстраивать под систему. Иногда это идет ему на пользу — стандартные модули программы заставляют отказываться от устаревших методов работы и внедрять более передовые. Но гораздо чаще бывает иначе: в жертву приносят уникальные и весьма перспективные направления бизнеса. В принципе новую систему можно было бы доработать и приспособить под них, но это сделало бы

и без того дорогой и долгосрочный проект еще более затратным.

Как же объединить ИТ- и бизнес-стратегии? Прежде чем планировать модернизацию ИТ-системы, руководители компании должны добиться, чтобы программисты разобрались в сути ее бизнеса, а ИТ-отдел занял достойное место в организации. Лучше, если ИТ-директор будет напрямую подчиняться президенту или исполнительному директору компании (как в Shinsei), а не финансовому директору (как чаще всего бывает). Это повысит статус системщиков, и все будут воспринимать их всерьез.

С другой стороны, руководству надо понять возможности ИТ. Глава Shinsei Масамото Ясиро и его преемник Тьерри Порте потратили много времени на это. Порте часто общается с Джеем Двиведи: они встречаются минимум раз в неделю. Кроме того, президент не реже чем раз в месяц заходит в ИТ-отдел. Порте считает, что, как глава банка, он «должен уметь объяснить клиентам и сотрудникам особенности ИТ — это нужно, чтобы соответствовать нынешним и будущим потребностям бизнеса своих клиентов».

Планируя ИТ-проект, важно ставить во главу угла те цели, кото-

рые компания хочет достичь в ближайшембудущем. Часто фирмы уделяют все свое время

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

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

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

Работая с посетителями, сотрудники видят, какие операции даются людям особенно трудно. Информация с передовой быстро доходит до разработчиков ПО, и они улучшают сервисность программы. Например, когда-то, чтобы открыть счет или перевести деньги, нужно было заполнить бумажный бланк и передать его операционисту, а тот уже сам вводил информацию в систему. Но клиенты часто брали не тот бланк или делали ошибки. Чтобы избавить их от многократного переписывания, бланки стали заполнять сами сотрудники банка. Операционист задает клиенту вопросы и вводит его ответы в систему — посетителю остается лишь проверить и подписать документ.

Стремиться к простоте

Философ Уильям Оккам утверждал, что чем проще теория, тем она совершеннее (принцип неумножения сущностей). Этот принцип верен и для корпоративных ИТ-систем: нужно свести к минимуму количество применяемых стандартов. Сетевые протоколы, операционные системы, используемые платформы — в идеале для каждой категории нужно выбрать всего один стандарт. Часто компании так

и начинают, но со временем стандартов становится все больше: это происходит и в результате слияний с другими фирмами, и в ходе развития собственного бизнеса.

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

Cтандартные требования. Стандартизация главных компонентов — важнейшее условие принципа «сначала дороги — потом дома». Как авиакомпания Southwest Airlines выигрывает оттого, что в ее парке самолеты только одного типа — Boeing 737, так и любая компания, создавшая простую ИТ-инфраструктуру, может повторно использовать ее элементы и оптимизировать процессы. Кроме того, простую инфраструктуру ИТ-специалисты обычно знают досконально. Развивать такую систему легче и дешевле, компания тратит меньше времени на поддержку и больше — на разработку новых функций.

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

Двиведи жестко вводил принцип стандартизации. Он всегда советовался с ключевыми специалистами, но не ждал, когда будет достигнут консенсус по тому или иному вопросу. Одно из самых его радикальных решений заключалось в том, чтобы отказаться от больших компьютеров — мэйнфреймов, на которые обычно устанавливают банковские программы, и заменить их серверами на базе процессоров Intel. Это был огромный шаг вперед, ведь в большинстве японских банков и финансовых организаций всего мира тогда стояли мэйнфреймы: их ценили за быстродействие и надежность. Но они обходились слишком дорого (годовые затраты на обслуживание мэйнфрейма составляют 15—20% от его первоначальной цены). К тому же программное обеспечение для старых больших машин обычно написано на каком-нибудь специально для них разработанном и уже порядком забытом языке. Даже знакомым с ним специалистам бывает трудно разобраться в коде чужой программы. Неудивительно, что, перейдя на серверную платформу, банк сразу же стал ежегодно экономить до $40 млн. Кроме новой платформы серверов Двиведи и его коллеги выбрали и другие стандарты, такие как ПК Dell, операционная система Windows, интернет, IP-телефония и простой формат обмена сообщениями между бизнес-системами.

Простота и повторное использование. Чтобы технологии не сковывали работу банка, будь то обслуживание физических лиц, инвестиционная деятельность или коммерческие проекты, Двиведи и его команда хотели создать архитектуру, которая позволила бы Shinsei быстро реагировать на зарождающиеся потребности бизнеса. При этом они действовали просто и очень последовательно. Как только перед компанией появлялась новая задача, ее дробили на составляющие и для каждой искали техническое решение. Прежде всего программисты перебирали готовые модули и компоненты своего ПО — нельзя ли применить их? Если в компании готового решения не находили, то искали его у разных поставщиков. Если же и это не приносило результата, банк обращался к одному из своих пяти или шести индийских партнеров-разработчиков. Они и создавали нужный модуль.

Как на деле работает метод Двиведи, показывает история проектирования и внедрения в Shinsei новой сети банкоматов. В 2000 году все японские банки брали с клиентов комиссионные за пользование банкоматами — как своими, так и чужими. Банкоматы стояли в отделениях и доступны были только в часы работы банка. В Shinsei хотели, чтобы люди могли снимать деньги или совершать другие операции бесплатно и круглосуточно, но понимали, что при традиционной сетевой архитектуре — вроде той, что построили у себя конкуренты, этого не достичь. Собрали проектную группу из сотрудников бизнес- и ИТ-подразделений. Они подробно определили, что банк хочет предложить клиентам, после чего разбили задачу на максимально простые составные части. Это позволило найти новые более эффективные решения. К примеру, обычно банкоматы соединялись с системами бэк-офиса специальными дорогостоящими каналами. Но ведь с тем же успехом в этих целях можно пользоваться и интернетом. Конечно, интернет-канал был не так надежен, как специальная линия, однако разработчики нашли простой выход из ситуации: сделать систему с двумя подключениями к интернету, которые обслуживаются двумя разными провайдерами. При сбое одного канала происходит автоматическое переключение на другой. Эта система оказалась надежнее, чем действующая в большинстве банков, да и стоила она в десять раз дешевле. Новый метод работы позволил Shinsei создать сеть круглосуточных банкоматов, которые предоставляли более широкий набор услуг, чем банкоматы конкурентов, и брали гораздо меньшие комиссионные.

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

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

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

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

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

Модульный принцип стал ключевым в стратегии банка. По словам Двиведи, с его помощью Shinsei «осваивает новые направления, удовлетворяет потребности организации по мере их возникновения... всегда идет в ногу со временем и никогда не забегает вперед». Посмотрим, как создавалась система обработки кредитных заявок. Систему внедряли поэтапно по трем причинам: программисты хотели, чтобы руководство убедилось, что они точно выполнили поставленную задачу, чтобы менеджеры

и пользователи не испугались чрезмерной автоматизации и чтобы можно было быстро устранять технические проблемы. Для начала продемонстрировали, что система может корректно обрабатывать 20—30 кредитных заявок в день. Затем пропускную способность увеличили до 200—300 заявок, и наконец, до шести тысяч. После этого в банке вообще перестали рассматривать обращения «вручную».

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

Не давите на сотрудников

Часто крупные ИТ-проекты терпят неудачу не потому, что система плоха, а потому, что пользователи не хотят с ней работать. В иных компаниях слишком жестко навязывают сотрудникам новую программу, и это вызывает у них протест. Люди просто не понимают, зачем им тратить время и силы на освоение другого ПО.

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

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

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

Подчиненные Двиведи создали канал обратной связи, по которому клиенты, сотрудники бизнес-подразделений и технические специалисты присылают свои замечания и просьбы — последнее время ежедневно поступает по сто писем. Предложения и сообщения о сбоях системы автоматически преобразуются в электронные заявки на поддержку отладчиков, которые должны на них оперативно отреагировать. Если в отведенный срок это не делается, запрос переправляется начальству. После устранения проблемы инициатор обращения получает уведомление.

Благодаря каналу обратной связи руководство увидело недочеты своего ипотечного кредитования. Клиенты, подающие заявки на жилищный кредит, не раз жаловались, что уже послали в банк требуемые документы, но система якобы их «не видит» и все еще считает недостающими. Менеджеры получали автоматические уведомления об этих претензиях, и, когда накопилась некая критическая масса, группе сотрудников, в том числе из ИТ-отдела, поручили найти и устранить причину сбоя. Оказалось, банк посылал клиентам список необходимых документов, но люди не всегда понимали, чего именно от них хотят, и отправляли не то. ИТ-систему усовершенствовали: сейчас она автоматически определяет комплект документов для конкретного человека и посылает ему образцы. Теперь люди гораздо быстрее собирают документы, а банк — их обрабатывает, что, разумеется, не может не нравиться клиентам.

Изменения в Shinsei вряд ли можно назвать революционными. Банк и не претендует на это — суть метода в постепенности. Когда совершенствование становится частью повседневной работы, сотрудникам незачем совершать трудовые подвиги, а руководству — нагнетать пафос, пытаясь их воодушевить. • • • В настоящее время компании тратят на ИТ около 5% своих доходов. Но это в среднем, разброс по фирмам большой, но еще больше разница в пользе, которую они извлекают из потраченных денег. С течением времени решить и без того непростую проблему выбора подходящей ИТ-системы, способной поддержать бизнес-стратегию, обеспечить конкурентное преимущество и стать основой для развития бизнеса, становится все труднее. Это и понятно, ведь с появлением более дешевых компьютеров, расширением сетевых возможностей и появлением поставщиков из развивающихся стран количество вариантов ИТ-систем множится, они изменяются и усложняются с каждым днем.

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