19.11.2010 в отеле “Катерина” в Москве (Шлюзовая наб., дом 6) пройдет интересное мероприятие, посвященное JD Edwards.
Основные докладчики: Джон Шифф, Вице президент Oracle JD Edwards, который расскажет о стратегии развития системы, а также Хартмут Визе с докладом о новых возможностях и индустриальных решениях в JD Edwards E1 v.9.
Отчет с фотографиями и презентациями с Oracle Day 2010 Moscow доступны на следующем ресурсе www.oracleday.ru.
Если кто-то не читает Стивена Чана (которого категорически рекомендую всем тем, кто занимается технологиями EBS), привожу ссылку на нелицеприятный материал о работе последнего java-плагина Sun JRE 1.6.0_22 (он же JRE 6u22, он же 1.6.0_22-b04) с OEBS.
Сегодня, после очередного обсуждения сайзинга под ERP систему, решил изложить мою версию процесса выбора и приобретения оборудования в письменной форме.
Мотивы и цели IT-директора или руководителя проекта внедрения информационной системы всегда понятны и прозрачны. С самого начала имеется желание знать, а во-сколько обойдется внедрение той или иной системы (и вопрос покупки «железа» возникает чуть ли ни сразу).
Предлагаю разобраться.
Процесс внедрения системы обычно делится на несколько этапов, а именно:
1. Предпроект
2. Концепт
3. Прототип
4. Тестирование
5. Пилот
6. Эксплуатация
Этапов проекта может быть сколь угодно много, но основные именно эти. По моим наблюдениям, на большинстве проектов вопрос покупки «железа» под промышленную систему встает на самых ранних фазах. Я отлично понимаю, что перед стартом проекта высшее руководство требует вполне конкретного и обоснованного бюджета и мало кому понравится, когда проект начинает вылезать за рамки утвержденных сумм. И если несколько человеко-дней на консалтинг в плюс или в минус к бюджету не столь критичны, то, например, неправильно выбранное и закупленное серверное оборудование — достаточно серьезная головная боль.
Как снизить риски при выборе оборудования и заложить необходимые суммы в бюджет?
Все начинается с дизайна технической архитектуры системы. Большинство систем имеет трехзвенную архитектуру и т. д. и все такое прочее. Обладая этими знаниями рисуется определенная картинка с серверами баз данных, серверами приложений, концентраторами, шкафами, источниками бесперебойного питания и т. д. Выясняются требования бизнеса к системе, а именно, сколько система может простаивать на профилактике, лимиты на восстановление системы, время отклика при работе с системой и много другое, что может повлиять на количество и мощь оборудования. Если бизнес требует 24×7x365, то встает вопрос о резервном центре и возможности/невозможности использования его мощностей при работе в штатном режиме. В результате число серверов может увеличиться вдвое.
Приведу схемку 24×7x365
С одной стороны, все понятно, вот они все наши «железяки», бери и считай. Но! Не все так просто. Предположим, что у нас имеется необходимость вести разработки и их где-то тестировать (на самом деле и предполагать не нужно, без этого не обходится ни один проект). Сразу встает вопрос о системном ландшафте, включающем в себя системы разработки, тестирования и саму промышленную систему. А ведь это тоже оборудование, которое следует иметь ввиду и без которого нельзя, но его нет на схеме, представленной выше. А резервное копирование? А средства коммутации, серверные комнаты, шкафы под оборудование, энергоснабжение, кондиционирование?
Предположим, что под разработку и тестирование у нас имеется старое оборудование, сетевая инфраструктура вполне устраивает и нам действительно необходимо «железо» только под промышленную систему.
Итак, процесс закупки оборудования:
1. У нас есть схема системы (например, которая приведена выше).
2. Мы выбрали «железного» вендора, к которому больше душа лежит или продукция которого является стандартом нашей организации.
3. Мы (предположительно) знаем количество пользователей, которые будут работать в системе и их системные роли (кадровики, коммерсанты, производственники, бухгалтера и прочие финансисты).
4. Имея на руках перечисленные выше данные, обращаемся к «железному» вендору за расчетом и коммерческим предложением. У крупных вендоров имеются специализированные конфигураторы для популярных промышленных информационных систем, которые на основе заполненных опросников (обычно заполняются совместно с «железным» вендором), произведут выбор оборудования, составление спецификации и ее расценку.
5. Цифры, полученные пункте 4, следует внести в бюджет, защитить его и на этом успокоиться.
6. Начать проект и настройку системы на том оборудовании, которое было выбрано под эти цели (из имеющегося или закупленного специально для начальных стадий проекта). Согласитесь, чтобы настраивать систему силами нескольких консультантов (даже десятков), супердома от известных «железных» брендов не требуются.
7. Один из самых важных пунктов. Система настроена и начато тестирование. Именно в этот период можно получить реальные цифры. Узнать сколько ресурсов потребляют пользователи и смоделировать нагрузку, с которой придется справляться промышленной системе.
8. Имея на руках расчеты из пункта 7 можно возвращаться к спецификации вендора и смотреть, насколько мы ошиблись. Ошиблись в большую сторону, хорошо. Сэкономим. В меньшую, тоже неплохо, потому как приобрети мы оборудование на ранних фазах проекта, что бы мы с ним в дальнейшем делали? Ситуация неприятная, но на самом деле не фатально критическая. Все таки «железо» можно масштабировать по вертикали (добавляя процессоры и оперативную память), а современные информационные системы масштабируются горизонтально (за счет добавления серверов приложений или узлов в кластер серверов баз данных).
9. Приобретаем «железо» для промышленной системы.
10. Запускаем систему в промышленную эксплуатацию на приобретенном оборудовании.
Еще один аргумент, почему не следует спешить с покупкой серверного оборудования. Сколько в среднем идет проект внедрения системы? Год! В течении этого года многое может измениться. Как минимум, выбранное оборудование несколько морально устареет и скорее всего подешевеет. Плюс ко всему, на рынке может появиться более интересное «железо».
Деловой инновационный форум Oracle Day 2010 в Москве 27 октября 2010 года.
Подробности мероприятия и регистрация доступны ЗДЕСЬ.
Дополнительная информация
За дополнительной информацией по участию в мероприятии просьба обращаться в Оргкомитет Oracle Day по тел. +7 (495) 647 0970
