вводил информацию в систему.
Но клиенты часто брали не тот
бланк или делали ошибки. Что-
бы избавить их от многократ-
ного переписывания, бланки
стали заполнять сами сотруд-
ники банка. Операционист за-
дает клиенту вопросы и вводит
его ответы в систему — посети-
телю остается лишь проверить
и подписать документ.
Стремиться к простоте
Философ Уильям Оккам утверждал,
что чем ироше теория, тем она со-
вершеннее (принцип неумножения
сущностей). Этот принцип верен
и для корпоративных ИТ-систем:
нужно свести к минимуму коли-
чество применяемых стандартов.
Сетевые протоколы, операцион-
ные системы, используемые плат-
формы — в идеале для каждой
категории нужно выбрать всего
один стандарт. Часто компании так
и начинают, но со временем стан-
дартов становится все больше: это
происходит и в результате слияний
с другими фирмами, и в ходе раз-
вития собственного бизнеса.
ИТ-решения для конкретных за-
дач бизнеса тоже должны быть мак-
симально простыми и допускать
применение одних и тех же под-
систем в разных модулях. Надо так-
же помнить, что сбои происходят
в любой системе, и предусмотреть
механизмы, позволяющие миними-
зировать их последствия.
Стандартные требования. Стан-
дартизация главных компонентов —
важнейшее условие принципа «сна-
чала дороги — потом дома». Как
авиакомпания Southwest Airlines
выигрывает оттого, что в ее пар-
ке самолеты только одного типа —
Boeing 737, так и любая компания,
создавшая простую И'Г-инфраструк-
туру, может повторно использовал»
ее элементы и оптимизировать про-
цессы. Кроме того, простую инфра-
структуру ИТ-специалисты обыч-
но знают досконально. Развивать
такую систему легче и дешевле,
компания тратит меньше времени
на поддержку и больше — на раз-
работку новых функций.
Выгоды стандартизации хорошо
известны ведущим поставщикам
пакетных систем. Они предлагают
пользователям проприетарные
стандарты — и на этом получают
дополнительную прибыль. К сожа-
лению, большинству ИТ-руководи-
телей не хватает полномочий или
упорсгва, чтобы держать оборону
при появлении новых платформ.
Поэтому бизнес-менеджеры тоже
должны разбираться в технологи-
ях. Ведь именно они должны оце-
нивать альтернативные варианты
и не допускать появления чуж-
дых компонентов, которые могут
разрушить единство ИТ-системы.
Двиведи жестко вводил принцип
стандартизации. Он всегда совето-
вался с ключевыми специалистами,
но не ждал, когда будет достигнут
консенсус по тому или иному во-
просу. Одно из самых его ради-
кальных решений заключалось
в том, чтобы отказаті>ся от больших
компьютеров — мэйнфреймов, на
которые обычно устанавливают
банковские программы, и заменить
их серверами на базе процессоров
Intel. Это был огромный шаг впе-
ред, ведь в большинстве японских
банков и финансовых организаций
всего мира тогда стояли мэйнфрей-
мы: их ценили за быстродействие
и надежность. Но они обходились
слишком дорого (годовые затра-
ты на обслуживание мэйнфрейма
составляют 15—20°ь от его перво-
начальной цены). К тому же про-
граммное обеспечение для старых
больших машин обычно написано
на каком-нибудь специально для
них разработанном и уже порядком
забытом языке. Даже знакомым
с ним специалистам бывает трудно
разобраться в коде чужой програм-
мы. Неудивительно, что, перейдя
на серверную платформу, банк сра-
зу же стал ежегодно экономить до
$40 млн. Кроме новой платформы
серверов Двиведи и его коллеги
выбрали и другие стандарт!»!, такие
как ПК Dell, операционная система
Windows, интернет, 1Р-телефоння
и простой формат обмена сообще-
ниями между бизнес-системами.
Простота и повторное исполь-
зование. Чтобы технологии не
сковывали работу банка, будь то
обслуживание физических лиц,
инвестиционная деятельность или
коммерческие проекты, Двиве-
дн и его команда хотели создать
архитектуру, которая позволила
бы Бінпієі быстро реагировать на
зарождающиеся потребности биз-
неса. При этом они действовали
просто и очень последовательно.
Как только перед компанией появ-
лялась новая задача, ее дробили на
составляющие и для каждой иска-
ли техническое решение. Прежде
всего программисты перебирали
готовые модули и компоненты
своего ПО — нельзя ли применить
их? Если в компании готового ре-
шения не находили, то искали его
у разных поставщиков. Если же
и это не приносило результата, банк
обращался к одному из своих пяти
или шести индийских партнеров-
разработчиков. Они и создавали
нужный модулі».
Как на деле работает метод Двн-
веди, показывает история проек-
тирования и внедрении в Яііітеі
новой сети банкоматов. В 2000 году
I
Руководители компании должны
добиться, чтобы программисты
разобрались в сути ее бизнеса.
hdr russia.ru і Сентябрь 2008
Harvard Business Review —
Россия
111
предыдущая страница 114 Harvard Business Review Russian 2008.10 читать онлайн следующая страница 116 Harvard Business Review Russian 2008.10 читать онлайн Домой Выключить/включить текст