SAP Business One. Строим эффективный бизнес

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

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

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

• Масштабируемость

• Надежность

• Управляемость

• Опора на стандарты

У разных компаний этот список может варьироваться и включать дополнительные пункты, но эти базовые принципы присутствуют в любом варианте списка. Рассмотрим их внимательнее.

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

Найти следы этих программистов было уже невозможно, код программы недоступен, а на ней держится работа всей небольшой торговой компании. Обратившийся ко мне директор поинтересовался — что же ему теперь делать? К сожалению, типичный путь — увеличивать число процессоров до двух, а потом и до четырех, — в силу «особенностей мышления» программистов был для него закрыт. Фактически он мог только рассчитывать на увеличение тактовой частоты и производительности одного процессора. А тем, кто знаком с ценовой политикой производителей процессоров х86, хорошо известно, что самые быстрые процессоры последних моделей обычно стоят непропорционально своей производительности дорого. Кроме того, прирост производительности составляет не более нескольких десятков процентов в год, что явно не успевало за темпами роста этой компании.

И что же оставалось делать? Мне пришлось дать совет выбросить эту программу и купить масштабируемую систему — т.е. систему, написанную с учетом будущей потребности в увеличении производительности и нагрузки, использующую в своей основе масштабируемые технологии.

О нелинейности масштабируемости очень интересно рассказывает в своих презентациях компания Sun Microsystems. Они приводят историю или, возможно, байку про компанию, которая решила заняться грузовыми перевозками в городе и подошла к этому делу очень серьезно. Специалисты компании тщательно исследовали рынок и выяснили, что типичный заказ включает перевозку коробки весом от 3 до 20 килограмм на расстояние от 5 до 15 километров. На основании этих данных они выбрали наиболее экономически эффективный автомобиль для своей компании — FIAT Uno (что-то вроде нашей Оки) и закупили партию этих автомобилей для своих курьеров. К сожалению, первый же заказ, который они получили, был на перевозку пианино!

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

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

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

Основное значение этого параметра: оценивать устойчивость системы к сбоям, включая такие экстремальные ситуации, как глобальные катастрофы или «маски-шоу». Современные технологии позволяют создавать исключительно эффективные системы устойчивые практически к любым внешним воздействиям, вплоть до уровня трансконтинентальных кластеров. Уровень надежности определяется процентом времени, которое система находится в рабочем состоянии. Скажем, 99,999%, или, в просторечье «пять девяток», обеспечивает такой уровень надежности, что в течение года система будет в нерабочем состоянии всего несколько часов. Нечасто, но встречается ситуация, когда заказчик, прочитав о таких надежных системах, требует у поставщика реализовать такую же надежность для своих решений. Технически это реализуемо, но… очень дорого. Каждая следующая «девятка» в степени готовности системы обходится в несколько раз дороже предыдущей.

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

При всей анекдотичности этой истории она отражает основное правило ИТ — данные в системе могут стоить дороже всей системы.

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