Владимир Баронов - Информационные технологии и управление предприятием

При выборе компонентов КИУС решаются следующие вопросы:

• заказная или тиражируемая;

• отечественная или зарубежная;

• весовая категория – от локальных до крупных интегрированных и/или их отдельных модулей.

Основные недостатки заказной разработки обычно объясняются так:

• трудозатраты и стоимость соизмеримы с затратами на тиражируемую систему (такие продукты должны реализовываться большими коллективами аналитиков, проектировщиков и программистов);

• использование тиражируемой системы менее рискованно, чем заказной разработки;

• тиражируемая система внедряется поэтапно и частично может быть доступна в рабочем режиме гораздо быстрее, чем заказная.

В табл. 8.1 приведены основные результаты анализа перечисленных подходов по ряду важнейших параметров, таких как стоимость, время, работоспособность и др., демонстрирующие преимущества использования тиражируемых систем в качестве компонентов КИУС.

Таблица 8.1.

Сравнение заказных разработок и тиражируемых систем

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

• масштабностью тиражируемых систем;

• тонкими отличиями реализации технологий основных бизнес-процессов;

• одинаковостью маркетинга (ключевые слова, характеризующие различные системы, практически одни и те же, – единая информационная среда предприятия; режим реального времени; независимость от законодательства; интеграция с другими приложениями; поэтапное внедрение и т. п.).

Тем не менее интуитивно понятными критериями выбора тиражируемой системы являются:

• поддержка большинства функций, выявленных при анализе требований;

• поддержка концептуальной модели данных (информационной модели предприятия);

• наличие высокоуровневых механизмов разработки для компенсации отсутствующих данных и функций;

• функционирование на различных аппаратных платформах, гибкость;

• сложность сопровождения и администрирования;

• локализация, адаптация к российским условиям;

• деловые критерии продавца (прежде всего его опыт внедрения и надежность).

Основные отличия между зарубежными и российскими системами:

• зарубежные решения ориентированы на хорошо структурированную иерархическую систему бизнес-процессов предприятия;

• зарубежные системы, как правило, опираются на стандарты, которым процессы должны удовлетворять;

• зарубежные системы, направленные на автоматизацию управления, поддерживают полный набор управляющих функций: планирование – контроль отклонений (учет) – регулирование;

• российские системы более полно отражают национальные особенности, российскую учетную специфику;

• логика российских систем близка российским управленцам;

• российские системы более удобны в случае работы с неполными, недостоверными или конфиденциальными данными.

Отметим, что значительное число проектов в отечественной практике создания КИУС завершается неудачно либо имеет тенденцию неограниченного увеличения сроков внедрения при одновременном отсутствии значимых результатов. При этом объяснение причины неудачи является традиционным (и очень удобным для консультантов-внедренцев) – «предприятие не готово к внедрению». На самом деле основные причины неудач лежат в несколько иной плоскости.

Фактически не система настраивается под предварительно реорганизованные бизнес-процессы конкретного предприятия, а наоборот, предприятие перестраивается под систему (любимая фраза внедренцев – «мы проводим реинжиниринг под нашу систему»). При этом зачастую и сам выбор системы осуществляется не на основании детальных функциональных требований к соответствующему компоненту КИУС, а попросту навязывается поставщиком. В одном из последних бюллетеней MIT Sloan Management Review отмечается: «…от 30 до 75 % систем не соответствуют ожиданиям пользователей, главная причина – стремление подогнать бизнес-процессы предприятия под существующую технологическую инфраструктуру».

Детальное моделирование и анализ задач не проводятся по следующим причинам:

• это серьезная работа, требующая высокой квалификации исполнителей и соответствующей оплаты, а заказчика еще нужно убедить в полезности полученных результатов в виде отчетов;

• фирме-поставщику тиражируемого решения невыгодно выполнять такую работу, поскольку сравнительный анализ модели требований и функционала системы может привести к плачевным результатам, вплоть до потери заказчика;

• само внедрение на основании модели требований не оставляет шансов тиражировать фрагменты настроек и знания из других проектов;

• фактически настройки осуществляются членами проектной группы самого предприятия (бухгалтерами, экономистами, плановиками и т. п.), прошедшими короткое обучение, – консультанты лишь отвечают на их конкретные вопросы и решают вставшие перед ними проблемы.

Подход к оценке ТСО базируется на результатах аудита ИТ-инфраструктуры, основных процессах управления, ИТ-активах, операций ИТ-персонала и действий конечных пользователей. Сбор и анализ статистики по структуре прямых (HW/SW, операции, административное управление) и косвенных затрат (на конечных пользователей и простои) проводится в течение 12 месяцев. Полученные данные оцениваются по ряду критериев сравнения с аналогичной по бизнесу компанией.

В ТСО в качестве базы для сравнения используются западные типовые компании. Методика учитывает различия с отечественными компаниями посредством использования поправочных коэффициентов:

• по стоимости ИТ-активов (Cost Profiles) с учетом данных по количеству и типам серверов, персональных компьютеров, периферии и сетевого оборудования;

• по заработанной плате сотрудников (Salary and Asset Scalars) c учетом дохода компании, географического положения, типа производства и размещения организации (в крупном городе или нет);

• по конечным пользователям ИТ (End User Scalars) с учетом типов пользователей и их размещения (для каждого типа пользователей требуется различная организация службы поддержки и вычислительной инфраструктуры);

• по использованию методов лучшей практики в области управления информационными технологиями (Best Practices) с учетом реального состояния дел по управлению изменениями, операциями, активами, сервисному обслуживанию, обучению, планированию и управлению процессами;