Служба Рассылок Городского Кота

Новости "Планеты КИС" (КОРПОРАТИВНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ)
http://www.RussianEnterpriseSolutions.com
Выпуск 32 от 05/05/00

+ + +

Уважаемые подписчики! Мы начинаем понемногу увеличивать объемы публикуемой
информации - за счет оригинальных переводных материалов и ссылок на статьи
по ERP-тематике различных офф- и онлайновых изданий и сайтов. Если у вас
есть интересные обзорные и аналитические материалы или ссылки на материалы
по MRP/ERP на русском языке, пожалуйста присылайте!

+ + +

       Консультационная компания решила оказывать творческие услуги
       Марк Мелер, Sm@rt Reseller

Далласский системный интегратор Stonebridge Technologies, главная
специализация которого - управление отношениями с потребителями и
развертывание систем управления ресурсами предприятия, расширяет сферу своей
деятельности. В дополнение к своему основному бизнесу фирма предложила
клиентам помощь в самовыражении через "Всемирную паутину". Конечно, тягу
поставщиков услуг к творчеству в Интернете нельзя назвать чем-то из ряда вон
выходящим, однако большинство подобных проектов выполнялось за счет
приобретения других компаний.
"Я встретился с руководством восьми различных организаций, оказывающих
такие услуги, - поясняет Джим Шерифф, исполнительный директор Stonebridge, -
изучил опыт Sapient и некоторых других фирм, вышедших на этот рынок после
поглощения других компаний, но в конце концов избрал другой путь. Мы решили,
что лучший способ сгладить различия между технологией и творчеством - это
пригласить руководителей творческой команды и оказывать такие услуги
собственными силами".
По словам Шериффа, интеграторам по-прежнему приходится преодолевать
внутренний конфликт между технически мыслящими консультантами, стремящимися
к созданию "точных, повторяемых и поддающихся измерению" систем, и новыми
служащими, привлекаемыми к творческому процессу.
"Обычно ведутся бесконечные споры, - отмечает Шерифф, - в которых "технари"
пытаются убедить "художников" в невозможности реализации их проектов".
Stonebridge намерена предложить своим клиентам семейство услуг bRM по
"управлению торговыми марками фирм". Эта инициатива, как отметил Шерифф,
выходит далеко за рамки простого создания Web-узлов. Она включает в себя
такие области "управления отношениями в электронном мире" как интеграцию
баз
данных и процессов, разработку корпоративных приложений. В частности,
пользователи нового семейства услуг смогут заказать исследования и анализ
популярности своей торговой марки, разработку мероприятий, подчеркивающих
самобытность корпорации, выработку стратегии выхода на рынок электронной
коммерции, а также придание исключительной индивидуальности своему Web-узлу.
Шерифф отметил, что его фирма уже полгода оказывает подобные услуги,
заключив отдельные соглашения с некоторыми клиентами. А недавно ей удалось
заключить контракт с порталом электронного снабжения медицинскими
материалами и техникой MedCenterDirect.com, успешно обойдя при этом фирму
iXL
Он сообщил также, что новый проект bRM позволит создать еще от 35 до 50
рабочих мест, а к концу нынешнего года, как ожидается, принесет доход в
размере 30-50 млн. долларов. Со временем, считает Шерифф, доля подобных
услуг в традиционной интеграторской деятельности фирмы, возрастет в 5-10
раз.
Stonebridge уже заполучила в свои ряды Грега Кларка -
консультанта-ветерана, имеющего богатый опыт в продвижении торговых марок,
обслуживании онлайновых средств массовой и творческих разработках. Он занял
пост вице-президента по управлению торговыми марками клиентов.

+ + +

       НЕ МОЖЕТ БЫТЬ СУПЕРПРОЕКТОВ БЕЗ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
       Cutter Corp.

Если вы собираетесь создать виртуальную корпорацию в Интернете, вам
придется воспользоваться программным обеспечением. Если вы управляете своим
домашним оборудованием из офиса или машины, вы делаете это с помощью
программного обеспечения. Если электронная коммерция становится главной
тенденцией развития, - а об этом непрестанно твердят ведущие журналы для
деловых людей, - она, естественно, также становится полной заложницей
программного обеспечения.
Говорить о суперпроектах начала XXI века - одно удовольствие, однако нельзя
забывать и о поддержке существующих технологий. Ведь если нужное ПО не будет
разработано своевременно, или оно окажется недоступным по цене, - многие из
суперпроектов очень быстро канут в Лету.
Все сегодняшние проекты требуют программного обеспечения. Более того, это
ПО должно выйти на новый уровень взаимодействия и интеграции, ведь ему
придется работать в гораздо более "интеллектуальной" среде. А отсюда ясно,
что главными условиями успеха приложений остаются все те же: программный
продукт должен появиться, когда он нужен на рынке, и полностью отвечать всем
требованиям рынка (в частности, быть доступным по цене). Требования не
изменились, однако их жесткость возрастает сейчас во сто крат. Несколько
десятков лет назад, когда только начинали появляться системы планирования,
оценки и управления, большинство подобных продуктов приходилось
разрабатывать, что называется, с нуля, да и работали они, как правило,
совершенно независимо друг от друга. Другими словами, с самого начала стали
накапливаться частные проблемы оценки ПО и общие - управления его развитием.
Однако мало что было сделано для их решения.
Программная поддержка суперпроектов может поставить разработчиков ПО в
весьма сложное положение. Едва ли большинство организаций сможет заставить
своих сотрудников работать дольше или усерднее. Уже сейчас можно видеть, что
интерес к компьютерным наукам у студентов постоянно снижается, а
программисты все чаще покидают эту отрасль. Остается один выход: повысить
интеллектуальность труда. Сегодня в области разработки приложений отмечается
четыре тенденции, обещающие повысить производительность труда, но все они
еще больше усложняют задачу оценки этого процесса и управления им.

ВАЖНОСТЬ НАЧАЛЬНОГО ЭТАПА

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

ЗАКЛАДЫВАНИЕ ОСНОВЫ НОВЫХ ПРОЕКТОВ

Создание программного обеспечения для перспективных суперпроектов
невозможно без предварительной подготовки в ходе начального цикла
разработки. При этом не стоит забывать, что новый продукт в большинстве
случаев является дальнейшим развитием нынешнего поколения программных
средств. Для оценки масштабов, сроков и затрат на новую систему необходимо
четко уяснить, что сделано в этом направлении. Если из всей документации уже
выполненного проекта сохранился только исходный текст программы, вам
понадобится немало времени и усилий, чтобы разобраться в нем. А без такой
предварительной подготовки едва ли удастся составить реалистические планы, и
новое начинание, скорее всего, окажется в числе 75% неудачников из доклада
Standish.
Совершенно ясно, что тщательное документирование выполненной работы
сэкономит немало времени и усилий, которые в противном случае пришлось бы
затратить на повторение пройденного. Еще лучше, если документация,
используемая руководителями и разработчиками проектов, будет
стандартизирована. Шаг в этом направлении сделала Object Management Group,
утвердившая спецификацию единого языка моделирования Unified Modeling
Language (см. Grady Booch, James Rumbaugh, and Ivar Jacobson, The Unified
Modeling Language User Guide, Addison-Wesley, 1998). Стандартизированная
документация, к тому же, снижает затраты времени и сил на достижение
совместимости нового программного обеспечения с уже развернутыми системами.
А ведь все продукты, предназначенные для работе в Интернете или через него,
должны, безо всякого сомнения, обладать такой возможностью.

ВО ЧТО ОБХОДИТСЯ МНОГОРАЗОВОЕ ИСПОЛЬЗОВАНИЕ КОМПОНЕНТОВ?

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

ОПРЕДЕЛЕНИЕ ДОПОЛНИТЕЛЬНЫХ ЗАТРАТ

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

+ + +

       ХРАНИЛИЩА ДАННЫХ В ЭЛЕКТРОННОЙ КОММЕРЦИИ
       Cutter Corp.

Не секрет, что хранилища ERP-данных и приложения электронной коммерции
решают весьма сходные проблемы и взаимно дополняют друг друга. Обе
технологии, скажем, предусматривают такие базовые операции, как обеспечение
доступа к данным, их форматирование и интеграцию. Грамотно выполненная
система электронной коммерции обязательно требует интеграции Web-магазина,
как и любых других клиентских приложений, с серверной ERP-системой обработки
заказов и ей подобными производственными компонентами. Однако, чтобы
наладить полномасштабную поддержку приложений электронной коммерции,
инфраструктура хранения данных должна отвечать целому ряду дополнительных
условий. В частности, необходим круглосуточный, без выходных дней доступ в
реальном времени к самой свежей информации; нельзя забывать также об
использовании современных технологий, включая XML и Java. И, наконец,
хранилища данных, предназначенные для электронной коммерции, должны быть
охвачены "обратной связью", те есть, обеспечивать выполнение транзакций
на
основе накопленных данных. А это требует оснащения хранилищ данных
транзакционными функциями (они должны не только выполнять транзакции, но и
поддерживать принятие решений).

Вот тут и возникает первая проблема. Системы планирования ресурсов
предприятия, предлагаемые фирмами SAP (ее знаменитая R/3) и PeopleSoft
значительно упрощают обработку транзакций на предприятии, однако мало чем
могут помочь при принятии решений. Система SAP предлагает 15 тысяч
загадочных таблиц, а в продукте PeopleSoft текущие данные практически
невозможно декодировать для передачи в хранилище. Другая серьезная проблема
- неспособность ERP-систем генерировать сложные отчеты. В результате
компаниям зачастую приходится комбинировать данные продуктов SAP и
PeopleSoft с информацией, полученной из других систем, которые не имеют ни
малейшего отношения к управлению ресурсами предприятия и попросту
игнорируются производителями средств ERP.

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

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

О том, насколько трудно связать системы управления ресурсами предприятия с
приложениями электронной коммерции, явствует из результатов исследования,
недавно проведенного фирмой AMR Research. Из 800 опрошенных компаний лишь
15% или около того предоставляют своим клиентам и партнерам возможность
проверять состояние заказа непосредственно на Web-узле и только от 5% до 10%
позволяют им выполнять транзакции. Реальность такова, что, обратившись в
онлайновый магазин большинства компаний электронной торговли, вы:
- не сможете получить подтверждения своего заказа;
- не сможете проверить наличие товара на складе;
- не сможете изменить сделанный ранее заказ;
- не сможете ознакомиться с историей своего заказа (узнать, не размещали ли
подобный заказ другие служащие вашей компании);
- не сможете оперативно проверить ход выполнения заказа (обрабатывается он,
отправлен или подготовлен к отправке).

В самом деле, мало найдется узлов электронной коммерции, где уже налажена
полная интеграция с серверными системами. В большинстве онлайновых магазинов
полученный через Интернет заказ прежде всего поступает к служащему, который
вручную вводит его в ERP-систему. Как правило, заказав что-нибудь в
электронном магазине, вы быстро получаете в ответ сообщение типа "Доставка
заказанной книги обычно занимает 2-3 дня". Но не думайте, будто система тут
же проверила, есть ли нужная книга на складе, - это сообщение основано на
предположении, что товар имеется в наличии. Если окажется, что его нет, вас
уведомят, что книга заказана, или предложат другую такой же тематики.
Подобные методы пригодны, конечно, для большинства компаний электронной
торговли, предлагающих через "Всемирную паутину" сравнительно простые товары
наподобие книг, ювелирных украшений или компакт-дисков. Но они едва ли
удовлетворят те фирмы, которые торгуют сложным оборудованием, либо хотят
предложить своим клиентам и партнерам проведение совместных операций через
Интернет. Чтобы эффективно работать в таких направлениях, необходим очень
высокий уровень автоматизации. А он попросту невозможен без тесной
интеграции между клиентскими приложения электронной коммерции и серверными
системами управления ресурсами предприятия, которые обслуживают такие
жизненно-важные задачи, как обработка заказов, выставление счетов и
производство продукции.

Доступ к ERP-данным в электронной коммерции

Существует несколько способов доступа к данным управления ресурсами
предприятия из приложений электронной коммерции.

1. Прямой доступ

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

2. Метод промежуточного звена

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

3. Комбинация метода промежуточного звена с прямым доступом

Как видно из заголовка, данный метод сочетает в себе использование
промежуточного звена с непосредственным обращением к базе данных ERP. Здесь
используется специальный механизм перемещения данных, а система ODS
выполняет функцию посредника, который представляет данных, получаемые в
реальном времени из системы управления ресурсами предприятия, хранилищ
информации и других необходимых источников. При такой схеме необходим также
механизм брокера (посредника), направляющий запросы конечного пользователя в
хранилище данных или непосредственно в систему ERP в зависимости от
потребностей заказчика.

+ + +

Архитектура системы крупного предприятия - стратегический выбор
http://www.RussianEnterpriseSolutions.com/frames/f05001.html

Статья рассказывает о семинаре "Управление персоналом - стратегическое
направление развития предприятия", проведенном корпорацией Oracle, компанией
"Борлас" и Магнитогорским металлургическим комбинатом.

+ + +

Если статья снабжена ссылкой, значит в рассылке она публикуется в
сокращении

+ + +

Господа! Если у вас есть интересные материалы или ссылки на материалы по
MRP/ERP на русском языке (обзорные и аналитические; не по конкретным КИС!),
пожалуйста присылайте (большие материалы по предварительному согласованию).

+ + +

Выскажите свое мнение по обсуждаемым нами вопросам -- пишите на
Bobrovsky@RussianEnterpriseSolutions.com

Спасибо всем, кто присылает письма.

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

Ведущий рассылки: Сергей Бобровский

+ + +

Полные тексты статей, Форумы и другие материалы -- на сайте
http://www.RussianEnterpriseSolutions.com

Воспроизведение материалов "Планеты КИС" разрешается только при наличии
гипертекстовой ссылки на сайт

= = =