Что делать с унаследованными приложениями?

Андрей Орлов, директор стратегических проектов НЦИТ «ИНТЕРТЕХ».

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

Что бы вы сказали про специалиста, давшего вам такую рекомендацию: «При эксплуатации вашего дома следует избегать дождей и снегопадов»? Если вам удастся подавить в себе сильные эмоции, то вы, скорее всего, ответите, что не в состоянии управлять количеством дождей и хотите знать, как лучше защитить дом от катаклизмов. И больше с этим экспертом не будете иметь дел. Однако же пожелание хранить и обрабатывать всю информацию предприятия в рамках одного программного продукта от рекомендации нашего эксперта отличается мало.

Историческое наследие

Программное обеспечение крупной компании создается годами, а то и десятилетиями. За это время одни программные и аппаратные платформы успевают устареть, а другие — появиться и завоевать популярность.

Совсем не обязательно, что решения о частичной автоматизации бизнес-процессов компании были ошибочными. И отнюдь не всегда задачи автоматизации можно решить, постоянно сохраняя совместимость внедряемых приложений со всеми ранее внедренными.

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

Может ли руководство корпорации отказаться приобрести понравившуюся компанию только из-за того, что там эксплуатируется система учета от другого производителя или работающая на другой платформе? Вряд ли...

Не существует универсальных программных продуктов

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

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

Технологические нюансы

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

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

В чем наша цель?

Только ответив на этот вопрос, можно ответить на вопрос, вынесенный в заголовок статьи.

Любой информационный ресурс (программа, база данных, система, сайт и т.п.) обладает тремя характеристиками: полезность, достоверность, стоимость.

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

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

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

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

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

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

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

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

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

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

Что же делать?

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

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

Понимание того, что вопрос согласованного использования унифицированных и нормализованных мастер-данных не решается сам собой даже в рамках одной ERP-системы, появилось и у крупнейших разработчиков ПО. В их решениях стали появляться модули или системы, служащие для централизованного ввода, хранения и распределения общих данных.

Например, компания SAP уже несколько лет поставляет модуль SAP Master Data Management (SAP MDM) как раз для централизованного управления мастер-данными. Компания IBM в данном классе продуктов предлагает WebSphere Product Center, который еще недавно назывался IBM InfoSphere Master Data Management Server for Product Information Management. Уже несколько лет многими компаниями применяется и отечественный продукт Ontologic разработки НЦИТ «ИНТЕРТЕХ».

Семь раз отмерь

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

Прекращать использовать унаследованные приложения следует только тогда, когда они не удовлетворяют требованиям бизнес-заказчиков, становятся чрезмерно дорогостоящими в эксплуатации, принципиально не приспособлены к обмену данными с другими приложениями.

В остальных случаях достаточно обеспечить использование этими приложениями тех же данных, что и остальными приложениями.

Все права сохранены. Ссылка на источник

Директор ИС №12, 4 декабря 2008 г.