Обратная связь

Спасибо Илье Мельникову и Руслану Бондареву за статью «Банки как процессинговые фабрики» (Директор ИС, 2004, № 4). Материал очень ценный и полезный, отражающий зарождающиеся тенденции развития ИТ в крупных компаниях. Скорее всего, интеграция имеющихся модульных информационных систем средствами EAI станет таким же неизбежным моментом в автоматизации крупных корпораций, как и автоматизация банковской деятельности в настоящее время. Четыре года назад мы так же стояли перед выбором. В России, кроме решения CMA (которое использовалось в то время только в системе SPOT на ММВБ), были представлены IBM с линейкой продуктов WebSphere MQ, TIBCO (посредством Reuters) с ActiveEnterprise и ряд других (GE, BEA Systems).

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

EAI — один из нужных (а вскоре, возможно, и незаменимых) компонентов информационной системы банка. Решения уровня MessageFlow и тем более workflow позволяют автоматизировать подготовку описаний имеющихся бизнес-процессов наглядными средствами. Полученные иллюстрации описания представляют собой не просто красивую картинку как результат применения большинства CASE-систем, а реально действующее описание бизнеса, использующее графический язык, доступный аналитикам.

Но не стоит считать, что системы интеграции любого уровня абстракции решат все проблемы. В 2000 году на семинаре, посвященном интеграционной системе CMA PIE, прозвучала фраза, которая не потеряла актуальности и сейчас: «Каков бизнес — таков и процесс». Ключевую роль в успехе компании играют правильно построенные процессы, а системы EAI — всего лишь инструмент. В статье авторы перечисляют проблемы, на которые следует обратить внимание при внедрении интеграционного программного обеспечения. На мой взгляд, все они относятся к техническим. Главным является понимание сути систем EAI, всех преимуществ ее использования сотрудниками и руководителями бизнес-подразделений. По оценкам западных аналитиков, срок возврата средств от внедрения систем EAI составляет один год, что втрое меньше срока окупаемости систем ERP. Те же аналитики называют и другую цифру — стоимость первой транзакции, равную 1 млн. евро. Получить подобные результаты, внедряя продукты EAI через ИТ-службы в качестве универсального средства организации взаимодействия между приложениями, невозможно.

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

Учитывая возросший за последние два года интерес со стороны российских промышленных предприятий к вопросам управления производством, удивительно, что нет мнений по тематике статьи «MRP II — история и современность» Дмитрия Гаврилова (Директор ИС, 2003 № 3). В статье приведен грамотный подход к теме MRP, а о книге автора вообще следует сказать отдельно.

На мой взгляд, концепция MRP не является идеальной и, например, вопросы оперативного планирования на уровне цеха в этой концепции проработаны слабо. Естественно, в концепции MRP не представлены достижения в области математического моделирования и методов оптимизации, имевшие место в СССР и за рубежом. В качестве примера можно сослаться на книгу А.А. Первозванского «Математические модели в управлении производством» (М.: Наука, 1975. 616 с.). Тем не менее концепция MRP легче интегрируется в современные ERP-системы и реализуется при использовании современных баз данных, чем различные оптимизационные методы.

До выхода книги Гаврилова «Управление производством на базе стандарта MRP II. Принципы и практика» (СПб.: Питер, 2003. 352 с.) о концепции MRP можно было прочитать только на английском языке, например: Manufacturing Planning and control systems, by Thomas E. Vollmann, William L. Berry, D. Clay Whybark, 1992.

В книге грамотно переведена терминология, применяемая в концепции MRP. Очень ценным является то, что автор владеет терминологией как Американского общества управления производством и запасами (APICS), так и принятой в России для разработок по управлению производством. На протяжении всей книги параллельно с русскими терминами следуют английские. По крайней мере, теперь есть источник, к которому можно обратиться для подробного изучения основ концепции MRP.

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

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