Материал предоставлен ОАО "Айтекс-М".
тел (095) 255-22-32, 255-21-38
itex@mail.sitek.net
Приоритеты
С настоящего времени и до конца десятилетия большинство компании будет менять финансовые системы. Устаревшие, плохо интегрированные приложения отрицательно сказываются на эффективности ведения дел, требуют больших затрат на обслуживание и уязвимы перед проблемами 2000 года. Интерфейсы, построенные на терминалах, запутывают конечных пользователей. Трудно извлечь нужные финансовые данные, "Унаследованные" системы учета страдают отсутствием гибкости и оказываются источником постоянных раздоров.
Нужны новые интегрированные финансовые системы. Но в большинстве компаний они не являются единственным или важнейшим приоритетом при построении информационных систем. Чтобы предприятие отвечало и другим требованиям бизнеса, необходим ряд дополнительных решений.
Рекомендуемая здесь стратегия - реализовать новую систему на базе существующего в Вашей компании сервера S/390. Это позволит использовать уже установленное системное программное обеспечение, задействовать все навыки, приобретенные Вашим техническим персоналом, и обеспечить поддержку оборудования, обойдясь сравнительно небольшим наращиванием его конфигурации. При этом финансовую систему современного уровня можно построить при минимальных затратах времени, риске, нарушении нормального ритма работы и гораздо дешевле, чем в случае радикальных изменений платформы.
Децентрализация и распределенные вычисления имеют смысл для многих приложений. Но финансовые системы по своей природе массивны, они действуют в рамках всего предприятия. Все данные поступают в единый центр, анализируются и обобщаются. Работу удаленных пользователей сравнительно несложно организовать через локальные серверы рабочих групп, а доступ к финансовой информации - реализовать на базе технологии интрасетей. Сети с высокой пропускной способностью снимают необходимость в децентрализации обработки баз данных и приложений.
Кроме того, централизованные реализации на системах S/390 получат выигрыш от экономии в случае наращивания мощностей, меньшей сложности программного обеспечения, высочайшей доступности, целостности данных и безопасности среды мэйнфрейма.
В любой компании ресурсы, доступные для информационных систем, небезграничны. Радикальные решения оправданы, только если выгоды, которые они сулят, получить иначе нельзя. Но какой в них смысл, если другие способы позволяют добиться той же функциональности быстрее, проще и дешевле.
Решения на базе S/390. построенные на проверенных временем стабильных технологиях, работают во всем мире. Экономия времени, денег и сил, достигаемая за счет новых финансовых систем на базе S/390, распространяется и на все другие сферы Вашего бизнеса.
ВЫБОР
Давно устоялся неоспоримый принцип: выбор прикладного программного обеспечения определяется потребностями бизнеса. Соответственно и решения принимают те, кто отвечает за производство и финансы. Технологии, включая платформы, на которых выполняются приложения, отходят на второй план.
Второй, но - все равно важный. Технологии сильно влияют на уровень расходов и во многом предопределяют успех или провал. К сожалению, недостаточное понимание этих факторов - не редкость. И, как следствие, появляются неприятные сюрпризы.
Любая организация, которая присматривается к новым финансовым системам, должна учитывать технологические факторы в трех ключевых областях:
1. Затраты. Независимо от используемых платформ централизованные вычислительные операции почти всегда дешевле децентрализованных. В зависимости от степени концентрации, как показывает практика, себестоимость централизованных вычислений на 30-300% ниже себестоимости децентрализованных.
На затратах сильно сказывается и выбор платформ. Различия здесь могут варьироваться на порядок даже для функционально эквивалентных приложений. Заметно влияет на издержки и такой важный фактор, как сложность программного обеспечения. Сложные решения требуют больших процессорных мощностей, равно как и большей численности персонала, который реализует, настраивает и обеспечивает их работу: чем сложнее, тем дороже, а заодно и рискованнее.
Для финансовых систем ценовой фактор может оказаться не единственным и даже не главным. Вполне могут найтись веские причины для выбора дорогостоящего решения. Но такой выбор должен быть сознательным и основан на ясном понимании компромисса между высокой стоимостью и получаемым выигрышем. Увы, чаще встречается обратное. Многие предпочитают дорогостоящие решения, полагая, что сейчас доплачивают за экономию в будущем. А кто-то делает подобный выбор, даже не подозревая о существовании менее дорогих вариантов.
2. Масштабируемость. Всегда следует интересоваться, поддерживают ли приложения и платформы, на которых они выполняются, большое число пользователей и рабочие нагрузки, характерные для крупных компаний. Но такие вопросы задают редко, отвечают же на них - еще реже.
Часто исходят из того, что, если какое-то решение удачно сработало для предприятия, допустим, с 50 пользователями, то оно подходит - в том же виде - и организации с сотнями или тысячами пользователей. Но расширить маломасштабное решение технически сложно, а во многих случаях - просто невозможно. Даже если удастся преодолеть технические проблемы, все равно дублирование серверов, приложений, баз данных и увеличение численности персонала для поддержки большого количества пользователей окажется делом слишком дорогостоящим.
Вполне могут найтись веские причины для выбора решений с низкими уровнями масштабируемости. Но опять же, это должен быть осознанный выбор. Слишком многие руководители делают его, полагаясь лишь на свою уверенность - без всяких на то оснований, - будто данная система, развернутая на предприятии намного меньших масштабов, отвечает также потребностям, профилю и реальным рабочим условиям компании их масштаба.
3. Надежность. Это понятие включает доступность (т, е, способность системы к непрерывному функционированию при одновременной поддержке большого числа пользователей и пиковых рабочих нагрузок), целостность данных и безопасность. Их уровень сильно зависит от конкретных технологий и платформ, а значит, эти факторы также следует принимать во внимание, взвешивая себестоимость системы и возможный риск.
Стратегия "первопроходца" - когда предприятие идет на реализацию сравнительно новых, непроверенных решений - может оказаться очень полезной, если в будущем от нее удастся получить какие-то преимущества в конкурентной борьбе. Но выбор такой стратегии должен быть сознательным. Только тогда можно четко прогнозировать возможные риски и их последствия. А иначе предприятие превратится просто в "подопытного кролика".
АНАЛИЗ ЗАТРАТ
Мы детально проанализировали 5- летние затраты на вычислительные средства, эквивалентные по своей функциональности интегрированным финансовым системам с поддержкой 250, 500 и 1000 пользователей. Затраты на оборудование, обслуживание, программное обеспечение и персонал рассчитывались для 5 вариантов, показанных на рис.1
Децентрализованная - несколько UNIX-серверов Финансовые системы реализуются на уровне филиала или отраслевого подразделения (business unit - организационная единица крупного предприятия, занимающаяся конкретным видом бизнеса). Применяются отдельные серверы, каждый из которых обслуживает по 100 пользователей. Центральный сервер консолидирует данные с целью их анализа и распространения в рамках всего предприятия. Централизованная - единственный UNIX-сервер Единая финансовая система работает на единственном централизованном сервере. Для поддержки 250 пользователей применяется сервер с симметричной мультипроцессорной обработкой (SMP), а для конфигураций с 500 и 1 000 пользователей - серверы с массово-параллельной обработкой (МРР). Централизованная - несколько UNIX-серверов Множество финансовых систем базируются на SMP-серверах, расположенных в едином вычислительном центре. Выделенная S/390-система Единая финансовая система работает на выделенном сервере S/390. S/390-система с разделяемыми ресурсами Единая финансовая система работает на S/390-системе, на которой базируются и другие корпоративные приложения. |
Рис. 1. Варианты интегрированных финансовых систем
Результаты получены четкие и однозначные. Для типичной крупной организации можно ожидать, что размещение интегрированных финансовых систем на корпоративных S/390-системах будет в 2-4 раза дешевле, чем на централизованных UNIX-серверах, и в 4-7 раз дешевле, чем на децентрализованных UNIX-серверах. Затраты оказываются значительно меньшими, даже если применяется выделенная S/390-система. Сводка полученных результатов приведена в таблице на рис. 2.
| Кол-во пользователей | ДЕЦЕНТРАЛИЗОВАННАЯ | ЦЕНТРАЛИЗОВАННАЯ | |||
| Несколько UNIX-серверов, $ | Несколько UNIX-серверов, $ | Единственный UNIX-сервер, $ | Выделенная S/390-система, $ | S/390-система с разделяемыми ресурсами, $ | |
| 250 500 1 000 | 13 958 11 609 10 993 | Неприменимо 5 712 5 585 | 6 058 4 909 3 788 | 5 162 3 420 2 374 | 3 150 2 294 1 506 |
Рис. 2. Системные расходы на одного пользователя в год применительно к разным вариантам финансовых систем
СРАВНЕНИЕ ЗАТРАТ
Из проведенного анализа прямо вытекают следующие выводы:
Высокий уровень затрат вызнан главным образом дублированием оборудования, системного и прикладного программного обеспечения, баз данных и обслуживающего персонала для множества серверов, каждый из которых поддерживает относительно небольшие группы пользователей. Накладные расходы, связанные с персоналом, - и так довольно высокие для любого типа UNIX-платформ - при таком дублировании возрастают еще сильнее.
Более того, если организация желает консолидировать финансовые данные для аналитических или информационных целей, ей все равно понадобятся серверы централизованной базы данных. А это влечет расходы на дополнительные программно-аппаратные средства и персонал.
Вариант с несколькими UNIX - серверами требует двух или более SMP - серверов с разделенными между ними приложениями и пользователями. Он распространен и организациях, уже работающих с SMP - серверами, среди поставщиков этих серверов и на предприятиях, где хотят использовать кластеризацию (дублирование, установка избыточного числа серверов) для увеличения доступности своих систем. Этот вариант обходится в 1,4-1,6 раз дороже (в пересчете на одного пользователя), чем применение отдельных UNIX-серверов.
Однако большинству организаций вряд ли имеет смысл поступать таким образом. Ограниченная масштабируемость UNIX-серверов требует базирования больших приложений на выделенных машинах. Более высокая процессорная мощность и эффективность обработки баз данных у S/390 означают, что новые финансовые системы можно реализовать на корпоративных серверах с разделяемыми ресурсами, а это дает существенную экономию.
Вариант на базе S/390 с разделяемыми ресурсами в 4,4-7,2 раза дешевле децентрализованных UNIX-систем и в 1,9-3,7 раза дешевле вариантов на базе централизованных UNIX-серверов.
Подавляющее большинство организаций с числом пользователей от 250 до 1 000 уже имеют в своем распоряжении тот или иной мэйнфрейм. Его можно - сравнительно легко и недорого - модернизировать для поддержки новой финансовой системы. Расходы на содержание персонала могут не увеличиться вообще и даже несколько снизиться благодаря тому, что новая система позволяет экономить на обслуживании как приложений, так и ее самой.
Расходы на оборудование, системное и прикладное программное обеспечение и персонал сильно зависят от конкретного варианта и поддерживаемого числа пользователей (рис. 3).
В миллионах долларов
1 - Централизованная (S/390-система с разделяемыми ресурсами)
2 - Централизованная (выделенная S/390-система)
3 - Централизованная (единственный UNIX-сервер)
4 - Централизованная (несколько UNIX-серверов)
5 - Децентрализованная (несколько UNIX-серверов)
Рис. 3. Распределение затрат на различные варианты интегрированных финансовых систем
ЗАТРАТЫ НА ИЗМЕНЕНИЯ
Вывод новых систем на рабочий режим потребует также дополнительных "затрат на изменения". В их число обычно входят некоторые (или все) из перечисленных на рис. 4
Услуги по предустановке Анализ/определение требований, оценки конфигурации, системы затрат. Преобразование баз данных Преобразование финансовых данных, хранящиеся на мэйнфрейме в базу данных нового формата (если это возможно). Параллельные операции Отчисления по лицензии на системное программное обеспечение, обслуживание оборудования, содержание персонала, обслуживающего его персонала, а также другие расходы на остаточные операции на мэйнфрейме в переходный период. Затраты на персонал Переобучение оставшегося персонала, расходы на выходные пособия (если это необходимо) и затраты на набор нового персонала. Услуги по установке и первоначальному запуску Конфигурирование программно-аппаратных средств, настройка программного обеспечения, установка, системная интеграция гетерогенных сред, переобучение вспомогательного персонала и конечных пользователей. |
Рис. 4. Потенциальные затраты па изменения для новых финансовых систем
Некоторые затраты не зависят от конкретных платформ. Так, реализация новых финансовых систем на любой платформе обычно требует услуг сторонних специалистов. Однако общие затраты в организациях, переходящих с "унаследованных" приложений мэйнфреймов на UNIX-системы, будут значительно выше. При этом, как правило, требуется серьезное переобучение имеющегося персонала информационных систем и найм нового - для системного администрирования и прочих задач.
Конфигурирование, установка и интеграция UNIX-серверов и сетей тоже, как правило, требует услуг сторонних специалистов. Эта статья расходов будет особенно высокой для децентрализованных систем. При переходе к UNIX-системам следует планировать от 6 до 12 месяцев параллельной работы на мэйнфреймах, а в крупных организациях этот период может и растянуться.
ЗАЯВЛЯЕМОЕ И ДЕЙСТВИТЕЛЬНОЕ
Большинство поставщиков интегрированных финансовых систем может предъявить внушительные списки крупных компаний, использующих их продукты. Но что именно делают эти компании с их продуктами и насколько велики работающие у них системы? Реалии могут оказаться совсем иными. Так, рис. 5 иллюстрирует некоторые расхождения между тем, на что ссылаются поставщики, говоря о "крупномасштабных" установках интегрированных финансовых систем, и тем, что есть на самом деле.
Крупномасштабные установки интегрированных финансовых систем на базе UNIX-серверов - большая редкость. Это вовсе не значит, что UNIX-серверы не отвечают требованиям крупномасштабных финансовых систем. Но в отсутствие более веских свидетельств ясно одно: многие из организаций, решившихся на установку таких систем, скорее участвуют в эксперименте, чем получают конечный продукт.
Мы выявили большое количество работающих установок интегрированных финансовых систем на базе S/390 с числом пользователей от 250 до 1 000, а также пять - с числом пользователей свыше 1 000 и одну - с 4 000 пользователей. В основном эти системы эксплуатируются уже не менее двух лет.
| ЗАЯВЛЕННОЕ | ДЕЙСТВИТЕЛЬНОЕ |
| Систему использует компания, входящая в список Fortune 100. | Система установлена в одном отраслевом подразделении. |
| С системой работают более 400 пользователей. | В организации 400 пользователей на одном модуле. |
| Система охватывает свыше 800 пользователей. | Спустя два года после начала проекта в организации стало 150 пользователей; планы на их расширение пока весьма неопределенны. |
| Свыше 1000 пользователей в стандартной корпоративной системе. | В организации есть как минимум восемь подразделений, работающих с отдельными системами. |
| Система поддерживает один из крупнейших в мире банков. | Система используется как специализированное приложение для управления финансовыми операциями |
Рис. 5. Выборочная проверка ссылок поставщиков на крупномасштабные установки интегрированных финансовых систем
ПОЧЕМУ ТАК ВАЖНА МАСШТАБИРУЕМОСТЬ
Помимо ценового фактора, сеть еще дне причины на то, почему масштабируемость финансовых систем считается столь критичным требованием для крупных организаций:
Концентрация финансовых операций тоже порождает новые требования к крупномасштабным системам, действующим в рамках всей организации. Системы уровня подразделений и отраслевых отделов во многих компаниях консолидируются, что обеспечивает экономию расходов, сокращение времени цикла и улучшение доступа к финансовой информации. Па этот путь встают даже многонациональные корпорации, подразделения которых разбросаны по разным географическим точкам мира.
Следует учитывать и другой фактор. Консолидация, слияние и покупка одних компаний другими наблюдаются все чаще и чаще во многих отраслях мировой индустрии, которая вынуждена реагировать на отмену государственного регулирования цен, открытие внутренних рынков, изменение их структуры и появление новых конкурентов. Так, в Соединенных Штатах слияние и покупка одних компаний другими должны, как ожидается, уменьшить число банков, обслуживающих только физические лица. с более 8 000 в 1995 году до менее 2 000 к концу этого десятилетия. Аналогичные всплески консолидации ожидаются в сфере коммунальных услуг. промышленности, страховании, здравоохранении, торговле и других отраслях.
Что произойдет в организации, с трудом наладившей работу 250 пользователей с маломасштабной системой, когда число пользователей вдруг резко возрастет до 350 или 500? Очевидно, что наиболее предпочтительна та финансовая система, которую можно быстро и без проблем приспособить к росту числа пользователей.
Высоких уровнен консолидации можно достичь даже при наличии сравнительно низкоскоростных коммуникационных линии. Но задача, конечно, значительно упрощается с появлением новых сетевых технологий - таких как frame relay (поддерживающих скорости до 2 Мбит/с) и АТМ (до 2 Гбит/с).
Финансовая система нашей основной производственной компании, например, обслуживает теперь более 1 500 пользователей в 33 странах на пяти континентах - и делает это из единою центра обработки данных, расположенного в Соединенных Штатах. Компания использует глобальные коммуникационные линии с пропускной способностью 100 Мбит/с, что дает время отклика в пределах долей секунды. Требования большинства других организаций не столь высоки, и добиться концентрации им будет легче.
Тем не менее может быть достаточно приложений, для которых имеет смысл децентрализованная обработка. Правда, не совсем ясно место финансовой системы в таком профиле. Транзакции обычно обрабатываются централизованно, а пользовательские интерфейсы финансовых систем требуют ввода данных, принятия заявок или заказов, доступа к главным базам данным для запросов и отчетности и выполнения прочих аналогичных операций. Как показано на рис. 6, все это можно реализовать на клиентских персональных компьютерах (ПК), используя сервер рабочей группы или отдела для локальной поддержки нужных видов сервиса.
Рис. 6. Архитектура сетевой финансовой системы
При таком подходе - его часто называют "финансовой интрасетыо" - система легко приспосабливается к любым требованиям аналитиков и других специалистов. Серверы распределенной базы данных позволяют загружать финансовые данные на локальные ПК и обрабатывать их тоже локально. При достаточной пропускной способности сети таким сервисом можно охватить всех пользователей и обойтись без децентрализованной обработки приложений.
Эти тенденции носят глобальный характер. Даже если маломасштабная финансовая система сейчас удовлетворяет нужды какой-то организации, стоит призадуматься: а что будет через пять или хотя бы через пару лет? Большую систему легко смасштабировать в обратном направлении, чтобы она отвечала меньшим требованиям. Обратный процесс, даже если он технически возможен (что во многих случаях весьма спорно), будет гораздо труднее и дороже.
МАСШТАБИРУЕМОСТЬ ПЛАТФОРМЫ
Даже если интегрированная финансовая система способна поддерживать большее число пользователей, надо прояснить еще одну проблему. Достаточно ли масштабируема платформа, на которой она работает?
Важность этого вопроса часто ускользает из поля зрения специалистов в области информационных систем. Но сам принцип достаточно прост. Компактный автомобиль не смасштабировать так, чтобы он перевозил грузы, которые по силам тяжелому грузовику. Так же, как и самолет местной авиакомпании не превратить в Боинг-747. Анатолий можно придумать сколько угодно.
Компьютер в не меньшей степени ограничены исходной архитектурой. Многие современные архитектуры, в том числе большинство основанных на операционной системы UNIX, начинали свою жизнь с поддержки малого числа пользователей. Приложения в те времена были сосредоточены на предприятиях малого и среднего масштаба, а также и подразделениях и отделах более крупных организаций. Серверы этого типа все еще жизнеспособны и могут поддерживать достаточно широкий круг приложений. Но они не рассчитаны на тот тип крупномасштабных, критически важных для бизнеса рабочих нагрузок, которые с самого начала обрабатывались - а во многих организациях обрабатываются и до сих пор - системами на базе мэйнфреймов.
В их пользу работают два фактора:
Рис. 7. Слагаемые производительности крупномасштабных систем
Производительность крупномасштабных систем - сумма множества взаимозависимых слагаемых. Один из побочных эффектов этой ситуации таков: руководители, ответственные за принятие решении, и даже многие специалисты по информационным системам постоянно удивляются, почему серверы не обеспечивают те уровни производительности, которые можно было предполагать, исходя из результатов эталонных замеров. Проблема в том, что широко распространенные единицы измерения быстродействия - миллионов инструкции в секунду (MIPS) и транзакций в секунду (tps) - свидетельствуют лишь об одном слагаемом производительности всей системы. Это примерно то же самое, что оценивать качества автомобиля только по тому, насколько хорошо работает у него сцепление.
На практике, чтобы обеспечить производительность, эквивалентную хотя бы малой системе на базе мэйнфрейма, может понадобиться множество сравнительно больших серверов. Одна из лучших иллюстраций этому - опыт компании Hewlett-Packard, которая в начале 1996 года заменила несколько относительно малых, устаревших мэйнфреймов. Как показывает рис. 8, чтобы добиться примерно 200 "мэйнфреймовых" MIPS, потребовалась установка минимум 16 серверов.
| Мэйнфреймы | Заменители | Приложения |
| Amdahl 5990/1400 2 х IBM 3090/200J (Всего: 202 MIPS) | 4 х МРР - сервера 2 х 12-процессорных SMP - сервера (кластеризованных) 10 х других SMP - серверов | Обработка заказов Финансы/налоги Учет кадров/фонд заработной платы Принятие решений Другое |
Источник: компаний Hewlett-Packard
Рис. 8. Опыт замены мэйнфреймов в компании Hewlett-Packard
Один из ведущих поставщиков UNIX-серверов, например, опубликовал недавно результаты эталонного теста для отдельного модуля SAP R3, Sales and Distribution (S&D). Для поддержки 1 200 пользователей даже в лабораторных условиях понадобились целых семь 20-процессорных SMP-серверов и один 32-процессорный МРР - сервер.
Однако время отклика в этом эталонном тесте составило 1,5 секунды. Такой уровень, как правило, разочаровал бы конечных пользователей, которые ожидают отклик порядка долей секунды. А значит, надо было бы наращивать конфигурацию или число серверов (или и то и другое) минимум на 50%, если не больше. Для сравнения: рабочие нагрузки такого масштаба нормально обрабатываются системой с единственным мэйнфреймом.
Реальные крупномасштабные рабочие нагрузки требуют платформ, разработанных и оптимизированных специально для таких нагрузок. Мэйнфреймы подходят не для всех приложений. Никто ведь не использует Боинги-747 на местных авиалиниях. Но никто и не пытается использовать крошечные самолетики для транcатлантических перевозок сотен пассажиров. Даже самые передовые технологии информационных систем все же нуждаются в здравом смысле.
НАДЕЖНОСТЬ
Характеристики надежности не измеряются промышленными эталонными тестами. Только опыт эксплуатации в реальных условиях покажет, обладает ли система этими характеристиками.
Доступность означает для пользователя безостановочную работу системы. Добиться ее труднее, чем кажется. У большинства перебоя, вероятно, ассоциируются со сбоями аппаратного обеспечения или с катаклизмами вроде штормов или наводнении. Но эти причины не главные. Как показывает рис. 9, подавляющее большинство проблем в крупных компаниях вызвано сбоями системного программного обеспечения (операционных систем, баз данных и различных подсистем) и прикладного программного обеспечения, а также ошибками операторов.
Рис. 9. Причины внеплановых остановок в корпоративных центрах обработки данных (по США)
Представленная диаграмма позволяет сделать ряд важных выводов. Сложные программные среды больше подвержены сбоям, чем простые, - хотя бы потому, что в них больше потенциально уязвимых мест. Это особенно верно в том случае, если ее компоненты - по отдельности или в каком-то сочетании - не проверены длительной эксплуатацией в нормальных рабочих условиях. Слабые места могут проявиться спустя годы, а то и десятилетия.
Риск операторской ошибки увеличивается пропорционально росту численности технического персонала, взаимодействующего с системен, и частоте его взаимодействия с системой. И вновь сложные системы более уязвимы.
Целостность данных и безопасность подразумевают отсутствие потерь и повреждений записей и исключение несанкционированного доступа. Любая из таких случайностей - в любой системе - может сильно повредить бизнесу. Особенно серьезными последствиями грозит повреждение финансовых записей.
Целостности данных и безопасности, как и доступности, добиться нелегко. Накопители, базы данных, системное и прикладное обеспечение должны быть очень стабильны, вести себя предсказуемо и предусматривать контролируемый доступ к ним. Записи следует постоянно дублировать, а копии хранить в безопасном месте - там. где по ним можно будет восстановить исходную информацию. Значимость всех этих возможностей со временем - по мере расширения числа пользователей финансовых данных - только возрастает.
Какую бы характеристику надежности мы ни взяли, системы на базе мэйнфреймов в целом и на основе S/390 в частности, бесспорно, надежнее любой конкурирующей платформы.
СТРАТЕГИЧЕСКИЕ АЛЬТЕРНАТИВЫ
Для организаций, стремящихся получить выигрыш от интеграции финансовых и рабочих данных, применение единственного, высокоинтегрированного программного пакета кажется просто обязательным. Многие даже не рассматривают возможные альтернативы.
Но прежде чем такие пакеты начнут доминировать в процессе принятия решений, следует задать себе одни очень важный вопрос. Если попытки массовой интеграции прикладных программ так часто сопровождаются сложностями, затратами и перебоями п работе, может, стоит поискать альтернативный способ достижения тех же стратегических целей?
И в большинстве случаев ответ будет положительным. Зачастую компоненты гораздо разумнее интегрировать в отдельные, более управляемые комплексы. Такой подход позволяет гибче реагировать на новые потребности, применяя более широкий круг программных пакетов, внутрифирменных систем и платформ. Тогда интеграции финансовых и рабочих (операционных) данных можно достичь сравнительно легко, используя хранилища данных и соответствующие методики.
Различия этих подходов иллюстрирует рис. 10.
Рис. 10. Подходы к интеграции финансовых и рабочих данных
АРГУМЕНТЫ ПРОТИВ МАССОВОЙ ИНТЕГРАЦИИ.
Проблемы можно суммировать следующим образом:
The Conference Board в докладе The Changing Global Role of the Finance Function за 1994 год отметила:
Такие возможности не требуют интеграции на уровне приложений. Достаточно хранилищ данных наряду с интрасетями, в которых применяются средства поддержки запросов к базам данных, систем принятия решений, распределенной отчетности и обмена электронными сообщениями.
Респонденты ставили интеграцию финансовых приложений выше (от 3,68 до 4,69 при шкале оценок от 1 до 5) интеграции с другими кросс - функциональными приложениями вроде систем учета материальных ресурсов или кадров.
Эти оценки соответствуют приоритетам 88% респондентов из финансовых организаций. Похоже, эта группа не хочет жертвовать интеграцией финансовых систем ради перспектив более широкой интеграции.
Они, действительно, не хотят этого - и по веским причинам. Большинство ведущих систем, интегрирующих финансовые и операционные данные, рассчитаны на поддержку бизнес - моделей распределенных производств. Доля производственных компаний в общем числе организаций, которые реализовали или начинают реализовать такие комплексы, составляет свыше 85%.
На распределенных производствах, вероятно, есть смысл в тесной интеграции рабочих систем с такими (функциями учета, как регистрация прихода и расхода. Например, скорость, с которой продукция расходится со склада, может оказаться решающим фактором конкурентоспособности предприятия. Для компаний, действующих по всему миру, особенно располагающих сетью географически разбросанных производств, может оказаться целесообразнее сместить обработку приложений ближе к пользователям,
В других видах производств стремление к интеграции слабее, а выгоды от нее минимальны. Там и в сфере обслуживания требования к интеграции совершенно иные. Многие из таких компаний не имеют удаленных фабрик. В этом случае лучше сосредоточить усилия на других слагаемых конкурентоспособности предприятия.
Но с увеличением масштабов растет число пользователей и операций, предъявляющих разные требования к системе, и все это тоже нужно учитывать при реализации такой системы. Уровень сложности, как показано на рис. 11, возрастает и выливается в повышенные расходы на конфигурирование, настройку и поддержку аппаратно-программных средств системы.
Рис. 11. Увеличение сложности массово - интегрированных систем
Результаты хорошо известны. Расходы на услуги консультантов, даже при создании небольших систем, как правило, десятикратно превышают затраты на само программное обеспечение. А при формировании крупномасштабных систем расходы на консультационные услуги в пределах 50-250 млн. долларов - обычное дело. Столь же обычным явлением становятся организационная неразбериха, сбои в управлении и отказ - на долгие годы - от других инициатив в области информационных систем.
Но негативные последствия чрезмерной сложности системы сказываются не только на начальном этапе - при ее создании. Они проявляются в течение всего срока ее службы. Постоянные модификации, необходимые для подстройки системы под изменяющиеся требования бизнеса, будут трудны, а по мере старения системы проблемы с сопровождением приложений будут нарастать экспоненциально. Особенно сложно будет переконфигурировать систему под кардинальные изменения структуры предприятия и всех его процессов.
Эти проблемы в конечном счете будут решены за счет более эффективного применения объектно-ориентированных архитектур. Но вряд ли это произойдет в нынешнем десятилетии. Поэтому сейчас целесообразнее другие, более реалистичные подходы.
| ПРОЦЕСС | СРЕДНЯЯ КОМПАНИЯ | ЭФФЕКТИВНАЯ КОМПАНИЯ |
| Материально-техническое снабжение | ||
| Costs per $ purchased | $0,025 | $0,01 |
Labor cost per transaction | $2,00 | $0,71 |
| Order to delivery time | 50 суток | 20 суток |
| Кредиторская задолженность | ||
| Cost per Invoice processed | $6,14 | $0,80 |
| AP costs as % revenues | 0,15% | 0,02% |
| % checks voided due to errors | 1,26% | 0,04% |
| Дебиторская задолженность | ||
| Cost per remittance | $0,71 | $0,01 |
| AR costs as % revenues | 0,43% | 0,04% |
| AR staff per $1 million revenues | 0,1 | 0,001 |
| Average days outstanding | 63 суток | 4 суток |
| Другие показатели | ||
| Cost per expense report | $7,60 | $1,29 |
| Cost to track flxed asset | $5,90 | $0,16 |
| Cost to payroll check | $3,00 | $0,95 |
| Budget cycle | 120 суток | 60 суток |
| Closing cycle | 5 -- 8 суток | <2 суток |
Источник: Arthur Andersen, The Hackett Group, Walker Interactive Systems
Рис. 12. Потенциальный выигрыш в эффективности процессов в области финансов и учета
По данным The Hackett Group, ведущей консультационной фирмы в области финансов, компании при таких инициативах могут обоснованно рассчитывать на экономию 30-150 миллионов долларов на каждый миллиард долларов дохода. Исходя из этих цифр, компания, скажем, с 3 миллиардами долларов дохода лишилась бы таким образом от 90 до 450 миллионов долларов потенциальной экономии за каждый год, в течение которого она следует интеграции финансовой и рабочих систем в ущерб сугубо финансовым целям.
Аргументы серьезные. Но посмотрим на проблему еще шире: есть ли смысл крупной организации замыкаться на одном-единственном программном комплексе, интегрирующем такой широкий круг бизнес - процессов и операций? Особенно если есть сомнения в его гибкости: адаптируем ли он к крупным изменениям в бизнесе и не потребует ли это чрезмерных и длительных усилий по его переконфигурированию и настройке - как в случае популярных массово - интегрированных систем?
Здесь существует очевидный риск того, что выбор бизнес - моделей будет определяться выбором программного обеспечения, а не наоборот. Если произойдет именно так, у компании резко сузится простор для стратегических маневров в будущем. Во многих отраслях промышленности большинства стран это было бы крайне опасно для любого бизнеса.
РЕОРГАНИЗАЦИЯ ПРЕДПРИЯТИЯ
Интеграция - не самоцель. Не следует ради нее жертвовать гибкостью, и она не должна препятствовать использованию лучших программных пакетов, инструментальных средств и платформ для приложении в масштабах всего предприятия.
Рис. 13 иллюстрирует альтернативную стратегию реорганизации предприятия, В этом примере рынок - на котором прекращено государственное регулирование цен - бросает серьезный вызов компании электроснабжения. От компании это требует быстрых изменений, причем во многих областях. Стратегия фокусируется на следующем:
Решения по базированию приложений будут приниматься в каждом случае отдельно. Крупномасштабные системы, действующие в рамках всей организации и/или требующие интенсивной обработки транзакций, останутся или будут реализованы на хосте S/390. Остальные будут базироваться на UNIX-серверах, мини-компьютерах, NT- или LAN-серверах.
Административные системы предприятия, включая финансовую, учета кадров, материально-технического снабжения и важнейшую для компании информационную систему по клиентам, предполагается заменить или модернизировать. Параллельно будут установлены электронная почта, подсистема управления рабочими потоками и сети обмена электронными данными (EDI).
Современный сервис-центр повысит качество обслуживания клиентов. Устаревшие "унаследованные" приложения для учета заказов, работ по обслуживанию, а также поиску и устранению неполадок будут заменены интегрированными системами управления активами. Эти и другие ключевые для компании системы будут соответствующим образом связаны друг с другом.
При централизации крупномасштабных баз данных и приложений и использовании проверенных временем технологий компания сумеет свести возможные осложнения к минимуму. Модульный "несистемный" подход позволит реализовать сразу несколько слагаемых конкурентоспособной производительности. Общие стандарты на сети и данные обеспечат нужную степень взаимодействия систем без проблем, свойственных массовой интеграции.
Главная цель - создать системы, настроить и запустить их как можно быстрее, проще и дешевле. Эта стратегия информационных систем поможет компании отвечать на вызовы, а не создавать проблемы.
| ХРАНИЛИЩА ДАННЫХ 1. Финансовые и операционные данные консолидируются с целью обеспечения их доступности пользователем в рамках всего предприятия ФИНАНСОВЫЕ СИСТЕМЫ 2. Интегрированные системы реализуются на S/390; 3. EDI - связи с поставщиками сокращают сроки закупок и расходы на них. 4. Электронная почта и сеть для управления рабочими потоками позволяет оперативно обрабатывать заявки, заказы на пробные образцы продукции и материально-техническое снабжение. Система поддержки принятия решений используется специалистами по финансам для комплексного анализа и планирования. УЧЕТ КАДРОВ 6. Система учета кадров на базе S/390 заменяет "унаследованные" приложения. МАРКЕТИНГ И ПРОДАЖИ 7. Для маркетинговых исследований устанавливаются новые системы. |
РАБОЧИЕ СИСТЕМЫ
8. "Унаследованная" информационная система по клиентам (CIS) перестраивается и обновляется. 9. CIS связывается с распределительной сетью через телефонные линии и электронную почту для управления перебоями в подаче электроэнергии и общественной безопасностью. 10. Автоматизированный сервис - центр связывается с CIS для выписки счетов, информирования о новом сервисе и управления перебоями в подаче электроэнергии, а также для поддержания системы управления диспетчерской службы 11. "Унаследованные" приложения заменяются интегрированными системами для обслуживания, управления работой и поддержки других функций управления активами. 12. Системы управления активами связываются с геоинформационными системами (GIS). Будущие инициативы будут направлены на интеграцию управления активами, CIS и операций по обслуживанию клиентов. 13. Для лучшей оптимизации работы сетей устанавливаются новые системы автоматизации распределения (DA). 14. Устанавливаются новые интегрированные системы контроля и мониторинга. 15. Новые системы автоматизируют ручные операции учета; инженерные чертежи переводятся в цифровую форму. |
Рис. 13. Стратегия реорганизации предприятия на примере компании по электроснабжению
СРАВНИТЕЛЬНАЯ БАЗА
Сравнение затрат проводилось с учетом полной комплектации программно-аппаратными средствами и персоналом для поддержки 250, 500 и 1 000 пользователей интегрированных финансовых систем на базе S/390 и UNIX-серверов применительно к полной пятилетке производственной работы; при этом использовались уже описанные варианты построения систем.
Финансовые системы конфигурировали так, чтобы они содержали семь функционально эквивалентных модулей, а именно: по учету кредиторской задолженности, дебиторской задолженности, главному гроссбуху (general ledger), материально-техническому снабжению, основным активам, управлению инвентаризацией и оценке расходов на оплату труда. Предполагается, что число и состав пользователей остается стабильным в течение всей анализируемой пятилетки.
Для сравнения использовали следующие интегрированные финансовые системы: Tamaris C/S от Walker Interactive Systems и функционально эквивалентный комплекс на базе UNIX класса "high end" от ведущего поставщика продуктов этого типа. Хотя содержание отдельных модулей у разных поставщиков немного варьировалось, общий набор функциональных возможностей был примерно одинаков.
Ряд других поставщиков предлагает менее дорогостоящие комплексы па базе UNIX. Мы отвергли их либо как неподходящие для крупных организаций, либо как не имеющие некоторых ключевых возможностей, либо по обеим причинам. Следует также подчеркнуть, что сравнивались финансовые комплексы, а не системы, интегрирующие в себе финансовые и операционные приложения. Затраты на все эти платформы (при любых вариантах) заведомо выше.
UNIX-платформы, использовавшиеся в сравнительных исследованиях, были SMP- или МРР - серверами от ведущих поставщиков этого типа систем, а платформы S/390-IBM 9672 и (для конфигураций с разделяемыми ресурсами на 500 или 1 000 пользователей) IBM 9021 под управлением MVS/ESA Version 5 с расширениями OS/ 390. Все затраты оценивались по состоянию цен на август 1996 года.
ЗАТРАТЫ, КОТОРЫЕ МЫ НЕ УЧИТЫВАЛИ
В расчетах не учитывались затраты на программно-аппаратные средства, персонал и сервис для сетей и телекоммуникаций, вычислительные средства у конечных пользователей (например, ПК, терминалы, принтеры), средства поддержки локальной инфраструктуры (например, локальные сети, файловые серверы, серверы печати, прокладка кабелей), а также расходы на обслуживающий персонал. Кроме того, не учитывались затраты на операционные системы, утилиты, аренду офисных помещений и другие статьи, которые могут быть предусмотрены в сметных расходах на информационные системы. Поскольку у разных организаций эти расходы сильно разнятся, их учет мог бы затруднить сравнение рассматриваемых нами вариантов. Но вряд ли они сильно повлияют на картину относительных затрат.
Аналогичным образом мы не учитывали возможный выигрыш от максимально эффективных реализаций, совместного использования каких-то сервисов, реорганизации самого бизнеса и других инициатив такого рода; этот выигрыш обычно принимают во внимание при изучении перспектив отдачи от капиталовложений. Этот выигрыш для функционально эквивалентных систем (независимо от того, на какой платформе или платформах они базируются), как правило, очень близок.
UNIX - серверы
Для всех UNIX-вариантов на UNIX - серверы устанавливались операционные системы, системы управления реляционными базами данных (в том числе соответствующие "параллельные" версии для МРР - серверов), средства системного администрирования и (где это возможно) средства кластеризации. Затем устанавливали полнофункциональные (со всеми 7 модулями) интегрированные финансовые системы, выбранные для сравнения.
Нагрузка по программному обеспечению масштабировалась с учетом конфигурации оборудования, так как важно было гарантировать, что серверы подвергаются реальной рабочей нагрузке и что они отвечают требованиям по уровню сервиса. Примененная здесь конфигурация, обычная для производственных UNIX-серверов, используемых в корпоративных бизнес - приложениях, включала более восьми миллионов строк кода и отвечала высоким уровням интеграции систем, подсистем и приложении. Это неизбежно оказывало сильное влияние на производительность.
Все конфигурации UNIX-серверов масштабировались, исходя из допущения, что задействовано 65% их мощностей. Нормы для UNIX-серверов, когда они еще могут поддерживать время отклика порядка долей секунды, составляют 60-70% загрузки их мощностей.
После этого мы по отдельности изучали следующие варианты:
1. Централизованные. По возможности в серверных конфигурациях учитывали задокументированный опыт разных пользователей и общепринятые промышленные нормы. Конфигурации на 500 и 1 000 пользователей в этом плане создавали проблемы, так как таких систем немного и опыт их эксплуатации почти не зафиксирован. В этом случае использовались другие источники.
К таким источникам относятся подробные аналитические исследования International Technology Group по 14 организациям, заменившим системы на базе мэйнфреймов UNIX-серверами, и сравнительное исследование производительности серверов, проведенное Computer Economics. Также использовали руководства и документацию, опубликованную компанией Hewlett-Packard (в ней, кстати, тоже предлагается "избыточно конфигурировать начальные системы", что позволяет делать оценки применительно к реальным рабочим нагрузкам): в них обобщен собственный опыт компании по недавней замене мэйнфреймов. Как оказалось, эти данные хорошо согласуются с данными Computer Economics и International Technology Group.
SMP-сервер класса "high end" был сконфигурирован как централизованная система на 250 пользователей. Однако построить аналогичным образом конфигурации для 500 и 1 000 пользователей на единственном сервере нельзя. С укрупнением конфигураций производительность SMP имеет тенденцию деградировать. Так, в пределах линейки серверов, предлагаемой выбранным нами поставщиком, переход с 4-происссорных конфигураций на 8-процессорные давал реальный прирост производительности примерно на 80%, а переход с 8-процессорной конфигурации на 12-процессорную давал лишь 20% прироста производительности. Дальнейшее наращивание конфигурации просто не имеет смысла.
Для вариантов, построенных на централизованных UNIX-серверах с 500 или 1 000 пользователей, применяли два отдельных набора конфигураций: односерверные конфигурации на базе МРР - серверов. которые эффективнее масштабируются при увеличении числа процессоров, и множественные SMP-серверы на базе 12-процессорных машин (это была максимально возможная конфигурация, предлагаемая выбранным для наших сравнений поставщиком).
SMP-серверы с большим числом центральных процессоров и более высокими уровнями эффективности мультипроцессорной обработки предлагаются другими поставщиками, но обычно они не используются как база для финансовых систем. Пока неясно, могут ли они справиться с поддержкой конфигураций на 500 или 1 000 пользователей. Более того, уровень цен на них лишь немногим меньше, чем на эквивалентные МРР - конфигурации.
Рассматриваемые нами конфигурации сведены в таблицу на рис. 14.
| ЧИСЛО ПОЛЬЗОВАТЕЛЕЙ | ЕДИНСТВЕННЫЙ СЕРВЕР | НЕСКОЛЬКО СЕРВЕРОВ |
| 250 | 1 х 12-процессорный 5MP | Неприменимо |
| 500 | 1 х 16-процессорный МРР | 2 х 12-процессорных SMP 1 х 2-процессорный SMP Хранилище операционных данных |
| 1000 | 1 х 32-процвспориый МРР | 4 х 12-процессорных SМР 1 х 4-процессорных SМР Хранилище операционных данных |
Рис. 14. Конфигурации централизованных UNIX-серверов
Изучавшиеся конфигурации с несколькими серверами допускали некоторое разделение рабочей нагрузки и применение распространенных средств администрирования, что существенно сокращало расходы на содержание персонала. Эти конфигурации включали дополнительный SMP - сервер, используемый как хранилище операционных данных ( что обеспечивает консолидацию данных от отдельных финансовых систем для анализа и в целях отчетности). Однако этот сервер сравнительно мал и слабо влияет на общие затраты по данному варианту.
Конфигурации не кластеризовали в смысле применения избыточного числа серверов ("стоящих" в резерве). Включение таких серверов привело бы более чем к двойному удорожанию.
2. Децентрализованные. Конфигурации строились на отдельных SMP-серверах под управлением UNIX, поддерживающих в среднем по 100 пользователей каждый. Исключение составил вариант с 250 пользователями, где мы исходили из предположения двух серверов на 100 пользователей и одного на 50,
Конфигурации центрального сервера оценивались по опыту пользователей, руководствам поставщиков (для конфигураций класса "high end") и промышленным нормативам. Поскольку обработка приложений децентрализована, системная нагрузка и масштабы общей конфигурации меньше, чем в случае, когда вся интегрированная финансовая система располагается на централизованном UNIX-сервере.
Из-за ограничений SMP-серверов в поддержке больших баз данных при расчетах для конфигураций на 1 000 пользователей в качестве сервера базы данных применяли МРР - сервер. Рассматриваемые нами конфигурации сведены в таблицу на рис. 15.
| ЧИСЛО ПОЛЬЗОВАТЕЛЕЙ | ЛОКАЛЬНЫЕ СЕРВЕРЫ | ЦЕНТРАЛЬНЫЙ СЕРВЕР |
| 250 | 2 ж 4-процессорный SMP (по 100 пользователей) 1 х 2-процессорный SMP (50 пользователей) | 4-процессорный SMP |
| 500 | 5 х 4-процессорный SMP (по 100 пользователей) | 8-процессорный SMP |
| 1000 | 10 х 4-процессорный SMP (по 100 пользователей) | 12-процессорный SMP |
Рис. 15. Конфигурации децентрализованных UNIX-серверов
Хотя 250 пользователей - это промышленная норма для интегрированных финансовых систем, мы обнаружили, что такие конфигурации искажают картину затрат для конфигурации на 500 и 1 000 пользователей. Так как сервер на 50 пользователей тоже требует капиталовложений в программно-аппаратные средства плюс системных операторов для поддержки сравнительно небольшого числа пользователей, общие затраты для такой конфигурации оказываются непропорционально высокими в расчете на одного пользователя.
Удельные затраты в расчете на одного пользователя в год при конфигурации на 300 пользователей составит 12 072 долларов, что ближе к конфигурациям на 500 и 1 000 пользователей.
S/390-системы
Сравниваемые системы были сконфигурированы следующим образом:
1. На все системы устанавливали полный набор системного программного обеспечения, включая операционную систему OS/390 (MVS/ESA Version 5 с эквивалентными версиями VTAM, TSO/E и других системных средств), а также соответствующие версии системы управления реляционными базами данных DB2, CICS/ESA, DFSMS и средства системного администрирования MVS/ESA. Конфигурация включала также семимодульный комплекс Tamaris C/S.
Системы конфигурировали, исходя из допущения, что задействовано 90% их мощностей. Нормы для S/390-систем, когда они еще могут поддерживать время отклика порядка долей секунды, составляют 90-95% загрузки их мощностей. Нагрузку по программному обеспечению масштабировали на оценки аппаратных конфигураций, учитывая промышленные нормативы для этого типа систем.
2. Выделенные S/390-системы конфигурировали, исходя из опыта пользователей, показывающего, что на 1 MIPS системы S/390 при установке Tamaris C/S в среде на базе MVS/ESA, описанной ранее, приходится в среднем по 15 пользователей.
Требования к мощности после этого завышали для надежности на 20%. В конце концов мы отобрали модели IBM 9672, показанные в таблице на рис. 16.
| ЧИСЛО ПОЛЬЗОВАТЕЛЕЙ | TAMARIS C/S, MIPS | +20% | Модель S/390 |
| 250 500 1000 |
17 33 67 | 20 40 80 |
9672-R12(21 MIPS) 9672-R22 (40 MIPS) 9672-R52 (88 MIPS) |
Рис. 16. Расчет конфигураций выделенных систем на базе S/390
3. Конфигурации S/1390 с разделяемыми ресурсами рассчитывались на базе оценок Computer Economics за 1996 год, согласно которым финансовые системы дают примерно 18% общей рабочей нагрузки мэйнфреймов в крупных американских организациях (в этом контексте - с доходом свыше 500 млн. долларов). Эта цифра, конечно, обобщенная, и истинные нагрузки - в зависимости от числа пользователей - могут существенно отличаться в ту или иную сторону. Рекомендуется оценивать число пользователей, исходя из собственного опыта.
Показатель 15 пользователей на I MIPS для Tamaris C/S умножали на коэффициент 5,56 (чтобы увеличить общую мощность с 18 до 100%) и добавляли 20% как запас по надежности. Основываясь на этой цифре, мы предпочли модели S/390, настроенные как серверы с общими для всего предприятия ресурсами. Этот процесс иллюстрирует рис. 17.
| TAMARIS C/S MIPS | x 5,56 | +20% | Модель S/390 |
| 17 | 95 | 114 | 9672 R63 (118 MIPS) |
| 33 | 183 | 220 | 9021-942 (220 MIPS) |
| 67 | 373 | 448 | 9021-9Х2 (472 MIPS) |
Рис. 17. Расчет конфигураций систем S/390 с разделяемыми ресурсами
По состоянию на август 1996 года единственными системами S/390 с достаточной мощностью для обработки двух 500- и 1000-пользовательских конфигураций без применения технологии Parallel Sysplex оказались устаревшие модели IBM ES/9000 9021. Можно ожидать, что эта картина изменится с внедрением более крупных систем на базе технологии CMOS/Parallel, примененной в серии 9672/
Расчеты проводили по консервативной схеме. В большинстве организаций интегрированные финансовые системы на базе S/390 заменят либо более старые учетно-финансовые комплексы на мэйнфреймах, либо COBOL-приложения, разработанные силами самого предприятия. Хотя они в основном компактнее (приблизительно миллион строк кода против двух - для Tamaris C/S) и хуже интегрированы, фактически будет задействован меньший процент разделяемых ресурсов S/390. Вполне разумно предположить, что число MIPS из таблицы на рис. 17 на самом деле уменьшится примерно на 25%.
ЗАТРАТЫ НА ПЛАТФОРМЫ
Их подсчитывали так:
1. Затраты на оборудование для UNIX-серверов и систем S/390 вычисляли по конфигурациям, описанным выше; при этом учитывали процессоры, память, дисковые накопители, устройства ввода/вывода и другие элементы, которыми обычно комплектуются новые машины. Для определения конкретного состава аппаратных средств у обоих наборов платформ использован руководства поставщиков и другую опубликованную информацию.
Затраты на приобретение и обслуживание оборудования подсчитывали в американских "уличных" ценах (т. е. в тех, что превалируют на рынке, а не в прайс - листах поставщиков) по состоянию на август 1996 года. Для систем S/390 мы использовали информацию о ценах, опубликованную Computer Economics, а для сравниваемых с ними UNIX-серверов - эквивалентные источники. В расчете затрат на обслуживание обоих наборов платформ учитывали гарантийный сервис в течение первого года эксплуатации.
2. Затраты на системное программное обеспечение для систем S/390 подсчитывали, исходя из опубликованных IBM цен Graduated Monthly License Charge (GMLC) на соответствующие программные группы. Аналогичным образом затраты на системное программное обеспечение UNIX-серверов вычисляли на основе опубликованных поставщиками цен; при этом - там, где это было нужно, - учитывали типы и масштабы машин, количество пользователей и число сопутствующих устройств. Цены поставщиков на практике могут варьироваться в определенных пределах. В расчеты включали начальные отчисления по лицензии и ежегодные расходы на поддержку (в течение первого года эксплуатации поддержка осуществляется бесплатно).
3. Затраты на системный персонал включали расходы на системное администрирование/управление, администрирование баз данных, управление накопителями, оперший и соответствующие категории персонала. Численность персонала для S/390 и UNIX - серверов оценивали но промышленным нормативам с учетом данных Computer Economics, COMPASS и Министерства Обороны США. Расходы на содержание персонала вычисляли но усредненным (для США) данным Computer Economics за 1996 год но .заработной плате, премиям, средней частоте командировок и обучения, а также но другим, аналогичным статьям расходов в крупных организациях.
ЗАТРАТЫ НА ПРИЛОЖЕНИЯ
Их подсчитывали так:
1. Расходы на программные продукты для Tamaris C/S и эквивалентных UNIX - комплексов на 250, 500 и 1000 пользователей для вариантов с централизованными серверами и сравнимые конфигурации для варианта с децентрализованными UNIX - серверами оценивали по ставкам на начальные выплаты по лицензиям и последующую ежегодную поддержку, установленным поставщиками этих продуктов.
Для всех вариантов скидки и групповое лицензирование, предлагаемые поставщиками, могут уменьшить уровень расходов по этой статье. Можно ожидать, что поставщики финансовых систем как для UNIX, так и для S/390 будут вести агрессивную ценовую политику, стремясь заполучить выгодные контракты на поставку.
2. Расходы на персонал оценивали, исходя из численности персонала, необходимого для сопровождения приложений с учетом непрерывных изменений и усовершенствований. Конкретные цифры расходов подсчитывали по усредненным (для США) данным Computer Economics за 1996 год по заработной плате, премиям, средней частоте командировок и обучения, а также по другим, аналогичным статьям расходов в крупных организациях.
Оценки численности персонала и средние расходы на его содержание в целом совпадали для интегрированных финансовых систем Tamaris C/S и на базе UNIX. Таким образом, мы использован одинаковые цифры расходов для всех вариантов с централизованным сервером, где эксплуатируется единственная копия программного обеспечения. Расходы для варианта с децентрализованными UNIX-серверами и варианта с несколькими централизованными UNIX-серверами подсчитывай отдельно. Затраты на эти варианты выше из-за того, что приходится дублировать копии прикладного программного обеспечения и обслуживающий персонал.
Следует отметить что эти затраты относятся только к программированию системного уровня для прикладных модулей, имеющие принципиальное значение. В большинстве организаций занимаются программированием на клиентском уровне для выборки, хранения, анализа и распределения финансовой информации, что значительно увеличивает численность персонала ( а значит, и расходы на него) для всех систем.
Удельные затраты в расчете на одного пользователя в год для обеих платформ и их приложений рассчитывали, исходя из общих пятилетних затрат на каждый вариант, поделенных на число пользователей и на количество лет (5).
ДЕТАЛИЗИРОВАННЫЕ СМЕТЫ РАСХОДОВ
Сметы, приведенные на рис. 18, детально отражают расходные статьи для всех вариантов интегрированных финансовых систем, рассмотренных в этом документе.
| Число пользо- вателей | Закупки оборудования (тыс. долларов) | Обслуживание оборудования (тыс. долларов) | Системное программное обеспечение (тыс. долларов) | Системный персонал (тыс. долларов) | ВСЕГО НА ПЛАТФОРМУ (тыс. долларов) | Удельные затраты на 1 пользо- вателя в год (долларов) |
ДЕЦЕНТРАЛИЗОВАННЫЙ ВАРИАНТ-НЕСКОЛЬКО UNIX-СЕРВЕРОВ | ||||||
| 250 | 1006 | 479 | 1934 | 8698 | 12117 | 9694 |
| 500 | 1720 | 810 | 3519 | 14056 | 20105 | 8042 |
| 1000 | 3139 | 1511 | 7341 | 26059 | 38050 | 7610 |
ЦЕНТРАЛИЗОВАННЫЙ ВАРИАНТ-НЕСКОЛЬКО UNIX- СЕРВЕРОВ | ||||||
| 250 | Не применимо | - | - | - | - | - |
| 500 | 1 233 | 647 | 2818 | 5190 | 9888 | 3955 |
| 1000 | 2796 | 14845 | 636 | 8681 | 18597 | 3719 |
ЦЕНТРАЛИЗОВАННЫЙ ВАРИАНТ-ЕДИНСТВЕННЫЙ UNIX-СЕРВЕР | ||||||
| 250 | 526 | 263 | 1315 | 3349 | 5453 | 4362 |
| 500 | 1086 | 592 | 3212 | 4555 | 9445 | 3778 |
| 1000 | 2052 | 1 137 | 6199 | 5844 | 15232 | 3046 |
ЦЕНТРАЛИЗОВАННЫЙ ВАРИАНТ-ВЫДЕЛЕННАЯ СИСТЕМА S/390 | ||||||
| 250 | 451 | 288 | 1 562 | 2032 | 4333 | 3466 |
| 500 | 922 | 589 | 1796 | 2416 | 5723 | 2289 |
| 1000 | 2064 | 1 312 | 2165 | 2622 | 8163 | 1 633 |
ЦЕНТРАЛИЗОВАННЫЙ ВАРИАНТ - СИСТЕМА S/390 С РАЗДЕЛЯЕМЫМИ РЕСУРСАМИ | ||||||
| 250 | 446 | 290 | 465 | 596 | 1797 | 1 438 |
| 500 | 787 | 433 | 908 | 779 | 2907 | 1163 |
| 1000 | 1293 | 731 | 908 | 894 | 3826 | 765 |
Число пользо- вателей | Прикладное программное обеспечение (тыс. долларов) | Персонал для приложений (тыс. долларов) | ВСЕГО НА ПРИЛОЖЕНИЯ (тыс. долларов) | Удельные затраты на 1 пользова- теля в год (долларов) | ВСЕГО НА СИСТЕМУ (тыс. долларов) | Удельные затраты на 1 пользователя в год (долларов) |
ДЕЦЕНТРАЛИЗОВАННЫЙ ВАРИАНТ - НЕСКОЛЬКО UNIX-CEPBЕРОВ | ||||||
| 250 | 4 182 | 1 148 | 5 330 | 4 264 | 17 447 | 13 958 |
| 500 | 6 970 | 1 948 | 8 918 | 3 567 | 29 023 | 11 609 |
| 1 000 | 13 490 | 3 426 | 16 916 | 3 383 | 54 966 | 10 993 |
ЦЕНТРАЛИЗОВАННЫЙ BAPИАНТ- НЕСКОЛЬKИХ UNIX-CEPBEPОВ | ||||||
| 250 | Не применимо | --- | --- | --- | --- | --- |
| 500 | 3 178 | 1 215 | 4 393 | 14 281 | 5 712 | |
| 1 000 | 6 356 | 2 970 | 9 326 | 27 923 | 5 585 | |
ЦЕНТРАЛИЗОВАННЫЙ ВАРИАНТ - ЕДИНСТВЕННЫЙ UNIX - СЕРВЕР | ||||||
| 250 | 1 569 | 551 | 2 120 | 1 696 | 7 573 | 6 058 |
| 500 | 2 138 | 689 | 2 827 | 1 131 | 12 272 | 4 909 |
| 1 00 | 2 880 | 826 | 3 706 | 7 41 | 18 938 | 3 788 |
ЦЕНТРАЛИЗОВАННЫЙ ВАРИАНТ - ВЫДЕЛЕННАЯ СИСТЕМА S/390 | ||||||
| 250 | 1 569 | 551 | 2 120 | 1 696 | 6 453 | 5 162 |
| 500 | 2 138 | 689 | 2 827 | 1 131 | 8 550 | 3 420 |
| 1 00 | 2 880 | 826 | 3 706 | 741 | 11 869 | 2 374 |
ЦЕНТРАЛИЗОВАННЫЙ ВАРИАНТ - СИСТЕМА S/390 С РАЗДЕЛЕННЫМИ РЕСУРСАМИ | ||||||
| 250 | 1 569 | 551 | 2 140 | 1 712 | 3 937 | 3 150 |
| 500 | 2 138 | 689 | 2 827 | 1 131 | 5 734 | 2 294 |
| 1 000 | 2 880 | 826 | 3 706 | 741 | 532 | 1 506 |
Рис. 18. Детализированные сметы расходы
ВЫВОДЫ
Несколько лет назад очевидным выбором были бы финансовые системы на UNIX. Но сейчас становиться ясно, что они не способны обеспечить эффективное соотношение цены и производительности для крупных организаций. Их приходится дублировать или децентрализовать таким способом, что это неприемлемо увеличивает технические сложности, расходы и сроки реализации. Тем временем аппаратная база S/390 существенно трансформировалась, ее себестоимость снижалась (и продолжает снижаться) быстрее, чем у любых других платформ; кроме того, для нее стали доступны сотни современных программных комплексов и инструментальных средств.
Новый импульс жизнеспособности систем S/390 придают и другие факторы. Во всех отраслях индустрии наблюдается тенденция к консолидации и возврату к централизации. Свыше 72% американских корпорации вернулись к централизации всех (или части) операций, связанных с информационными системами. Для международных корпораций эта цифра еще выше - 80%.
После децентрализации и разукрупнения 80-х и начала 90-х годов компании агрессивно движутся в обратном направлении. К этому повороту их вынуждают не только технологические изменения, но и фундаментальные перемены на мировых рынках и в условиях конкуренции, В исследовании, посвященном возврату к централизации информационных систем, которое было опубликовано в декабре 1995 года, ведущая организация по изучению частного бизнеса, The Research Board, очень точно охарактеризовала эту картину:
Усилившаяся конкуренция по всему миру жестоко наказывает компании, в которых структуры расходов обременены лишним персоналом или ресурсами... Фирмы пытаются решить сразу три задачи: интегрировать глобальные бизнес - процессы, сократить общие расходы на содержание своей инфраструктуры и исключить разнобой в локальных системах, который усложняет управление, но не приносит никакой пользы клиентам.
Клиенты стремятся получить максимальную для себя выгоду, и чаша их выбора все чаще перевешивается . в пользу цены, а не статуса компании. Чувствительность к ценовому фактору сохраняется даже в периоды экономического подъема - может быть, из-за сокращения реальных доходов в долгосрочном плане, а может быть, из-за старения населения, очевидного во всех развитых странах. Политика сдерживания цен за счет централизованной координации и интеграции ресурсов в этих условиях просто неизбежна...
Консолидация и возврат к централизации привел к кардинальному смещению равновесия "цена-выгода" для информационных систем в сторону высококонцентрированных, крупномасштабных систем, работающих на мэйнфреймах. Поэтому завтрашним день - это финансовые системы на базе S/390.
Но не обязательно дожидаться завтрашнего дня. На этих системах уже работают. Можете работать и Вы.