Книга
← К списку книгЗагрузка разделов…
активнаАктивные записи участвуют в каталоге и синках. Неактивная книга скрыта, но не удалена из базы.
Книга
ПРЕДИСЛОВИЕ
И ВВОДНАЯ ИНФОРМАЦИЯ
ВВЕДЕНИЕ
Этой главой начинается наш разговор о системах планирования ресурсов предприятий (ERP системах), и в ней мы остановимся на следующих вопросах:
Зачем изучать ERP системы?
Как ERP системы создают ценность?
Какова цель этой книги и проблемы, затронутые в ней?
Каково содержание этой книги?
Зачем изучать системы планированияресурсов предприятий?
Системы планирования ресурсов предприятий имеют огромное влияние и на мир бизнеса, и на мир информационных технологий, включая следующие аспекты:
ERP системы влияют на большинство крупных корпораций в мире;
ERP системы влияют на многие малые и средние предприятия;
ERP системы влияют на поведение конкурентов;
ERP системы влияют на требования к деловому партнеру;
ERP системы изменили природу консалтинговых компаний;
ERP системы — одно из основных средств реинжиниринга;
ERP системы распространили многие «лучшие практики»;
ERP системы дали клиент-серверным технологиям их первый корпоративный продукт;
ERP системы изменили природу подразделений информационных систем;
ERP системы изменили природу рабочих мест во всех функциональных областях;
Стоимость ERP систем высока;
ERP системы претерпели значительный рыночный рост.
ERP системы влияют на большинство крупных корпора^ ций в мире (Bowley 1998). Одну только систему класса ERP (SAP R/3) используют более 60% транснациональных фирм. Далее, согласно лидеру всемирной стратегии Артуру Д. Литтлу, компания, специализирующаяся на ERP системах (SAP), «покоряет мир. Почти каждая важная компания в той или иной степени находится в ее руках».
ERP системы влияют на многие малые и средние предприятия (Foley and Stein 1997). Влияние ERP систем не ограничивается крупными фирмами. В 1995 г. компания SAP получила 90% своих доходов от крупных транснациональных компаний, но ожидала получить к 1997 匚 50% своих доходов от малых и средних предприятий. Приблизительно 35% клиентов SAP в 1997 г. имели доходы ниже 200 млн. долларов.
ERP системы влияют на поведение конкурентов. 24 июня 1996 г. подразделение прикладных систем корпорации Oracle объявило, что «несколько компаний работали с Oracle Applications, включая Silicon Graphics, Inc. и корпорацию Quantum, в течение квартала, причем обе компании успешно провели крупномасштабные внедрения». Кроме того, в это же время она объявила, что «среди новых клиентов, появившихся за этот квартал,... компания Western Digital...» Western Digital была прямым конкурентом корпорации Quantum.
Когда одна корпорация внедряет ERP систему, должны ли ее конкуренты делать то же самое? Если программное обеспечение (ПО) дает конкурентное преимущество и/или может создать ценность, тогда, возможно, ответ — да. Но какое ПО выбрать компаниям, и кто должен обеспечить для них его внедрение? Можно предположить, что если одна компания успешно внедряет ERP систему для обеспе-
чения конкурентного преимущества, то эти же ПО и группа консультантов будут выбраны для внедрения ERP системы ее конкурентами, —в конечном счете, у кого может быть больше опыта в этой области? Однако какой в этом случае будет реакция фирмы, первоначально внедрившей ERP?
ERP системы влияют на требования к деловому партнеру. Как правило, внедрение ERP систем делает фирмы более «подвижными» в плане информации. Они могут лучше обрабатывать информацию и интегрировать ее в свои бизнес-процессы и процедуры принятия решений. Соответственно, деловым партнерам необходимо адаптироваться к изменениям, которые будут происходить в организациях, использующих ERP системы. Например, фирмы, использующие ERP системы, осуществляют операции в реальном времени и того же ожидают от своих партнеров. Кроме того, фирмы, внедрившие ERP системы, могут начать интеграцию системы в направлении цепочки поставок, продвигая эти системы в звенья цепочки поставок, включающие их партнеров.
ERP системы изменили природу консалтинговых компаний. ERP системы сыграли решающую роль в росте услуг компаний «большой шестерки» (с недавних пор ——«большой пятерки») и других фирм, оказывающих профессиональные услуги. Согласно Public Accounting Report (1998), услуги с привлечением программных пакетов ERP приносят от трети до половины всего дохода от консалтинговых услуг американских фирм, специализирующихся на предоставлении профессиональных услуг.
ERP системы — одно из основных средств реинжиниринга. В 1990 г. статья Хеммера по реинжинирингу вызвала интерес корпораций к ликвидации существующих у них бизнес-процессов (т. е. отказу от них). К сожалению после такой ликвидации многие фирмы не представляли, чем их заменить. Системы планирования ресурсов предприятия являются, возможно, основным средством решения данной проблемы: Джендрон (Gendron 1996) назвал ERP системы (в частности систему SAP R/3) «электронным воплощением» реинжиниринга, а Хеммер (Hammer 1997) отметил, что «SAP — это вынужденный реинжиниринг».
ERP системы распространили многие «лучшие практики». Системы планирования ресурсов предприятий базируются на так называемых «лучших практиках» — лучших способах осуществления бизнес- процессов. Система SAP R/3 включает более тысячи таких практик! Это значит, что любая фирма, которая устанавливает R/3, имеет доступ к множеству лучших практик. Более того, постоянно добавляют-
ся новые примеры ведения бизнеса. Как только новые лучшие практики найдены и введены в конкретные приложения, они становятся доступными для включения в новые версии системы R/3; как только новые версии становятся доступными, другие фирмы устанавливают их. Следовательно, существует цикл поиска новых лучших практик, ввода их в ПО и распространения их среди новых пользователей.
Следовательно, фирмы должны задавать следующие вопросы:
Какие бизнес-процессы дают нам преимущества в конкурентной борьбе?
Какие новые процессы могут дать нам преимущества в конкурентной борьбе?
Откуда нам известно, что в данных процессах есть что-то уникальное?
Сколь ценен этот процесс по сравнению с рядом широко доступных процессов?
Каковы будут затраты для этой лучшей практики по отношению к конкурирующим?
ERP системы дали клиент-серверным технологиям их первый корпоративный продукт. В начале 9Ох гг. модель клиент-сервер стала доступной технологией, имевшей много преимуществ по сравнению с существующими решениями на базе мейнфреймов. К сожалению, лишь ограниченное число программных продуктов было доступно для использования этих преимуществ. Системы планирования ресурсов предприятия изменили ситуацию, став одними из первых главных корпоративных приложений, работающими в архитектуре клиент-сервер.
ERP системы изменили природу подразделений информационных систем. Изначально, работа подразделений информационных систем заключалась в разработке, развитии и внедрении ПО. В настоящее время благодаря ERP системам функции разработки и развития выводятся за пределы предприятия. Системы планирования ресурсов предприятий удовлетворяют большую часть потребностей фирмы в ПО. Это изменяет основную природу подразделений информационных систем, и, в то время, как раньше требовались системные аналитики и программисты, теперь решающим является знание существующих пакетов ПО.
Изменились не только требования, но и стал более мобильным персонал этих подразделений. Изначально, персонал, обслуживающий информационные системы, имел представление только о конкретных традиционных приложениях, используемых данной фирмой.
С появлением ERP систем ситуация меняется, и знания могут быть использованы не только в одной фирме. Знания почти о любом ERP пакете могут использоваться не только в одной организации, но и во всем мире. Таким образом, так как использование пакетов ПО класса ERP возрастает, персонал, обслуживающий информационные системы, мобилен более, чем когда-либо.
Кроме того, такая мобильность изменяет консалтинговый бизнес, поддерживающий программные пакеты ERR
ERP системы изменили природу рабочих мест во всех функциональных областях. Системы планирования ресурсов предприятий изменили природу рабочих мест в функциональных областях, таких как производство. Как пишет Коркоран (Corcoran 1998):
Специалисты в области информационных технологий (ИТ) на производстве говорят, что ERP системы размывают границы между информационными технологиями и пользователями. Существует огромная потребность в пользователях или персонале по линии бизнеса, которые также владели бы информационными технологиями на профессиональном уровне. Но традиционные специалисты в области информационных технологий, знающие только технологию и ничего не знающие о бизнесе, не нужны сейчас, как когда-то. «Понимание бизнеса, возможно, самый важный аспект,——говорит Джоан Кокс, главный менеджер по информатизации сектора космических и стратегических ракет Lockheed Martin в Бетесде. — Важнее понимать, как должно работать предприятие, чем уметь программировать, —кроме тех нескольких мест, где SAP не делает того, что нужно, вам не придется кодировать».
Стоимость ERP систем высока. Согласно МЕТА group, средняя стоимость внедрения ERP системы ——15 млн. долларов при средней стоимости одного рабочего места 53 320 долларов. Эти оценки включают ПО, компьютерное оборудование, профессиональные услуги и затраты на содержание собственного персонала для полного внедрения, плюс два года поддержки после внедрения. Как заметили Ис- кейл, Котелир и Остин (Escalle, Cotteleer, and Austin 1999), стоимость ERP систем может достигнуть 2-3% доходов.
ERP системы претерпели большой рыночный рост. Согласно Фраю (Frye 1994), в 1993 г., коща началось развитие клиент-серверной технологии, доля пяти производителей ERP систем, работающих по модели клиент-сервер, составила 74 %: Oracle ——88 млн. долларов, SAP America — 71 млн. долларов, D&B Software — 30 млн. дол-
ларов и Computron — 17 млн. долларов. Общая прибыль составила 319 млн. долларов. В 1998 г. рынок лицензирования / поддержки составил 17,2 млрд, долларов, а в 2000 г. доходы ожидаются в размере 24,3 млрд, долларов (PricewaterhouseCoopers 1999). Рыночный рост систем класса ERP был огромным.
Как ERP сиаемы создают ценность?
Традиционные информационные системы изначально были функциональной основой для множества организаций или функциональных сфер, но не могли объединять их в случае их географической распределенности. Одну и ту же информацию собирали мносократно и во многих местах, и она была недоступна в реальном времени. Рабочие места и процессы были узко специализированы в соответствии с разделением труда и промышленной революцией. В результате некоторая информация никогда не выходила за пределы отдельных подразделений корпораций. Определение процессов и работ было направлено на то, чтобы информация удовлетворяла локальным требованиям. Когда же информация становилась «глобальной», информационные отчеты об одних и тех же событиях часто были разными. Таким образом, налицо была информационная асимметрия между различными локальными и функциональными группами и топ- менеджментом.
Системы планирования ресурсов предприятий предоставляют фирмам модели обработки деловых операций, которые интегрированы с другими видами их деятельности, такими как производственное планирование и управление человеческими ресурсами. Осуществляя стандартные процессы компании и обеспечивая ее единой базой данных (БД), охватывающей все ее виды деятельности и места расположения, ERP системы обеспечивают интеграцию ее многочисленных географически разделенных подразделений и функциональных областей. В результате, ERP системы привели к улучшению возможностей принятия решений, которые проявляются в широком ряде показателей, таких как сокращение запасов (сырье, полуфабрикаты и готовая продукция), сокращение штатов, ускорение закрытия финансового процесса и т. д. Таким образом, ERP системы могут быть использованы для того, чтобы помочь фирмам создать ценность. В частности, ERP системы способствуют созданию ценности, изменяя основную природу организаций множеством различных способов.
ERP системы интегрируют виды деятельности фирмы
По замечанию Хеммера (Hammer 1997): «Интеграция — отличительная характеристика SAP». Процессы планирования ресурсов предприятий являются межфункциональными, заставляющими фирму выходить за традиционные, функциональные и локальные рамки. Кроме того, различные бизнесс-процессы предприятия часто связаны между собой. Более того, данные, располагавшиеся ранее на различных неоднородных системах, сейчас интегрированы в еданую систему.
ERP системы используют ^лучшие практики»
Системы планирования ресурсов предприятий вобрали в себя более тысячи лучших способов организации бизнес-процессов. Эти лучшие практики могут быть использованы для улучшения работы фирм. Выбор и внедрение ERP систем требует внедрения таких лучших практик.
ERP системы делают возможной организационную стандартизацию
Системы планирования ресурсов предприятий делают возможной организационную стандартизацию различных географически разделенных подразделений. В результате подразделения с нестандартными процессами можно сделать такими же, как и другие подразделения, имеющие эффективные процессы. Более того, фирма может предстать перед внешним миром как единая организация. Вместо того чтобы получать разные документы, когда какая-то фирма имеет дело с разными филиалами или предприятиями данной компании, эта компания может быть представлена миру в виде единого общего образа, что ведет к улучшению ее имиджа.
ERP системы устраняют информационную асимметрию
Системы планирования ресурсов предприятий складывают всю информацию в одну и ту же основную БД, устраняя многочисленные информационные несоответствия. Это приводит к нескольким результатам. Во-первых, обеспечивается повышение контроля. Как сказал один из пользователей (Brownlee 1996, с. R17): «Если ты не выполняешь свою работу, я вижу, что что-то не было сделано». Во-вторых, открывается доступ к информации для тех, кому она нужна; в идеале, обеспечивается улучшенная информация для принятия решений. В-третьих, информация перестает быть предметом посредничества, так как она становится доступной и для руководства, и для служащих компании. В-четвертых, организация может стать «плоской»: так как
информация широко доступна, нет потребности в дополнительных малоценных работниках, чья основная деятельность — подготовка инфор- мами для распространения среди руководства и служащих компании.
ERP системы обеспечивают информацией
в реальном времени
В традиционных системах большое количество информации фиксируется на бумаге, а затем передается другой части организации, где она или переоформляется (обычно агрегируется), или переводится в компьютерный формат. С ERP системами большое количество информации собирается у источника и непосредственно помещается в компьютер. В результате, информация тут же становится доступной для других.
ERP системы обеспечивают одновременный доступ к одним и тем 氷е данным для планирования и контроля Системы планирования ресурсов предприятия используют единую БД, где большая часть информации вводится один и только один раз. Так как данные доступны в реальном времени, фактически все пользователи организации имеют доступ к одной и той же информации для планирования и контроля. Это может способствовать более согласованному планированию и управлению по сравнению с традиционными системами.
ERP системы способствуют взаимодействию
и сотрудничеству внутри организации
Системы планирования ресурсов предприятий также способствуют взаимодействию и сотрудничеству внутри организации (между различными функциональными и географически разделенными подразделениями). Наличие взаимосвязанных процессов приводит функциональные и географически разделенные подразделения к взаимодействию и сотрудничеству. Стандартизация процессов также способствует сотрудничеству, так как между процессами становится меньше противоречий. Кроме того, единая БД способствует взаимодействию, обеспечивая каждое географически разделенное и функциональное подразделение нужной им информацией.
ERP системы способствуют взаимодействию
и сотрудничеству между организациями
ЕКРсистема обеспечивает информационную магистраль для организации взаимодействия и сотрудничества с другими организаци-
ями. Фирмы все больше и больше открывают партнерам свои БД для облегчения снабжения и других видов деятельности. Чтобы данная система работала, необходим единый архив, которым могут пользоваться партнеры; и ERP системы могут быть использованы для содействия таким обменам.
Какова цель этой книги, и какие проблемы затронуты в ней?
Цель этой книги — изучить некоторые наиболее важные и интересные проблемы, примеры и идеи, относящиеся к ERP системам. Однако эта книга ——не энциклопедия по ERP системам. В ней мы фокусируемся на тех проблемах, которые важны для консультантов и менеджеров. Мы также останавливаемся на тех понятиях, которые более специфичны для ERP систем, чем для ПО в целом. Например, хотя проектный менеджмент важен для внедрения любой ERP системы, он остается все же проектным менеджментом, и большое количество материалов по проектному менеджменту информационных систем доступно в других источниках. В данной книге мы не останавливаемся на практических проблемах, так как эти проблемы варьируются от одного программного продукта к другому, и данную информацию можно получить из ряда других источников. Например, подробный анализ системы SAP можно найти в ASAP (1996) и Curran and Keller (1998). В этой книге мы редко останавливаемся на деталях, связанных с отдельными ERP системами, хотя конкретные системы иногда используются для иллюстрации определенных концепций.
Каково содержание этой книги?
В этой книге мы останавливаемся на пяти основных аспектах ERP систем:
базовая информация (глава 2),
системы и^их возможности (главы 3-6),
жизненный цикл ERP систем (главы 7-13),
электронная коммерция (глава 14),
риски (глава 15).
базов。;? информация
Чтобы управлять ERP системами, необходимы большой объем информации и знание других технологий, включая клиент-серверные
технологии, сети, системы управления реляционными БД(ихранили- ща данных), концепции ПО (включая готовое и традиционное ПО), концепции анализа требований (например, моделирование «как есть») и реинжиниринг.
Системы и их возможности
Анализ ERP систем и их возможностей начинается с производи- теле济 ERP систем и их партнеров. Рассматриваются некоторые мо- дули двух ERP систем и обсуждаются такие вопросы, как использование ПО от одного производителя или выбор подхода «лучшие из подобных». Кроме того, рассматриваются модели и процессы, лежащие в основе ERP приложений, и дается краткое описание того, как работают ERP системы. Затем приводится подробный анализ ввода и вывода данных в ERP системах для определения потенциальных источников затрат на эти системы и пользы от них. И, нако- нец, рассматриваются достоинства и недостатки реин*инирин「а «с чистого листа» по сравнению с реинжинирингом, «запускаемым ERP технологией».
Вопросы жизненного цикла ERP систем
DiaBbi третьей части этой книги описывают общую модель жизненного цикла процесса, который проходит фирма с ERP систе- мой- Этот цикл можно разделить на составляющие следующим образом:
Решение о внедрении ERP систем
Выбор ERP системы
Проектирование ERP системы
Нужно менять бизнес-процессы или ПО?
Выбор стандартных моделей, объектов и процессов
Внедрение ERP системы: сразу или поэтапно?
После запуска
Обучение (вопрос, касающийся все「о *изненно「о цикла)
Электронная коммерция
Системы планирования ресурсов предприятий обеспечивают информационную магистраль, которая может создать базис для раз- работки приложений электронной коммерции. В конечном счете, ERP системы должны интегрироваться с другими системами, или разработчики ERP систем должны выработать собственные решения для электронной коммерции. В любом случае ERP системы могут способствовать развитию электронной коммерции.
Риски
Во введении мы остановились на достоинствах ERP систем. Все же там, где есть огромные возможности для роста и создания ценности, есть также и огромный риск. Мы предлагаем модель, основанную на определении рисков на протяжении всего жизненного цикла системы.
Структура материалов книги
/лавы
В каждой главе мы обращались к сравнительно независимым частям материала по ERP системам. Однако от главы к главе материал собирается в единое целое. Для иллюстрации или выделения главных вопросов по ERP системам в книге были использованы различные примеры из реальной жизни. Эти примеры взяты как из литературы, так и из интервью, проведенных в нескольких компаниях.
Приложения
Приложения имеют три различные формы. Во-первых, существуют «большие приложения». В приложении Geneva Steel (приложение 3-1) рассматриваются результаты, ожидаемые от внедрения ERP систем, и некоторые аспекты изменений корпоративной культуры. В приложении Microsoft (приложение 9-1) рассматриваются различные организационные вопросы, связанные с выбором ERP системы, и анализируется вопрос, нужно или нет менять процессы или ПО. В приложении Quantum (приложения 11-1™11-3) рассматривается процесс внедрения.
Во-вторых, существуют «небольшие приложения». В приложении Quantum (приложение 5-1) анализируются виртуальные хранилища данных и то, как они стыкуются с ERP системами. В приложении Chesapeake Display and Packaging (приложение 8-1) дается взятый из реальной жизни пример процесса выбора фирмой конкретной ERP системы из многих. В приложении 8-2 подводятся итоги исследования, полученного мной от одного финансового директора. Данное исследование касается выбора ERP системы, сделанного его фирмой. При изучении примера компании X (приложение 12-1) исследуются некоторые вопросы оценки ERP системы предприятием средних размеров. В интервью с Лесом Потером (приложение 14-1) говорится о появляющейся форме ERP системы с поддержкой Интернета, в качестве примера используется продукт компании J.D. Edwards.
В-третьих, в приложениях дается более детальная информация по ERP системам. В приложении «Собственная или готовая» (приложение 7-1) рассматриваются некоторые вопросы внедрения ERP системы. В списке контрольных вопросов консалтинговой компании Deloitte Consulting, составленном после внедрения (приложение 12-2), приводится краткое резюме некоторой ключевой информации, полученной после внедрения.
Литература
ASAP [World Consultancy] (1996). Using SAP R/3. Indianopolis, IN: Que.
Bowley, G. (1998). «Silicon Valley,s Transplanted Sapling». Financial Times, March 27. Brownlee, L. (1996). «Overhaul». Wall Street Journal, November 18, pp. R12, R17. Corcoran, C. (1998). «ERP is Changing Manufacturing Jobs». InfoWorld, July 13.
Curran, T., and Keller, G. (1998). SAP R/3 Business Blueprint. Upper Saddle River, NJ: Prentice-Hall.
Escalle, C.,Cotteleer, M.,and Austin, R. (1999). «Enterprise Resource Planning (ERP)». Report no. 9-699-020, Harvard Business School, Cambridge, MA.
Foley, J, and Stein, T. (1997). «Oracle Aims at Applications Midmarket».
Information Week, July 7, p.30.
Frye, C. (1994). «With Financial Apps, DBMS Support Often Drives the Sale».
Software Magazine, June, pp. 55-7.
Gendron, M. (1996) «Learning to Live with the Electronic Embodiment of Reengineering». Harvard Management Update, November, pp.3-4.
Hammer, M. (1997). «Reengineering Work: Don't Automate, Obliterate». Harvard Business Review, July/August, pp. 104-12.
Hammer, M. (1997). «Reengineering, SAP and Business Processes». Unpublished presentation given at SAPPHIRE (Orlando, FL), August.
PricewaterhouseCoopers (1999). Technology Forecast, 1999. Palo Alto, CA: PricewaterhouseCoopers.
Public Accounting Report (1998). «Big Six Dominate Systems Integration Market».
July 31, p. 4.
2
СИСТЕМЫ И ТЕХНОЛОГИЧЕСКАЯ ПОДОПЛЕКА
Цель данной главы ——дать краткую вводную информацию по различным системам и технологиям, чтобы облегчить понимание вопросов, связанных с предметом ERR С этой целью здесь представлены основы обработки данных и работы в сети, баз данных, программного обеспечения, выбора ПО и реинжиниринга. Чтобы привязать материал данной главы непосредственно к ERP системам, в рамках рассмотрения каждой категории основная информация соотносится с соответствующими аспектами ERP концепции (в частности, на примере системы SAP).
Обработка данных
Первоначально обработка данных на предприятии по большей части базировалась на мейнфреймах. Однако примерно в 1993 г. (см. например, Frye 1994) более доступными стали версии приложений для обработки данных предприятий в рамках модели клиент-сервер.
Обработка данных мейнфреймами
В вычислительной среде мейнфреймов вся обработка данных выполняется единственным компьютером («шкафом»). Обычно пользователям разрешается использовать вычислительный ресурс — мейнфрейм — совместно (например, в режиме разделения времени). При этом пользователь обычно находится за терминалом, не наделенным способностями обработки данных (или за персональным компьютером, который эмулирует терминал).
Клиент-серверные вычисления
Со временем пользователь получил больше локальных вычислительных возможностей. В результате произошло перемещение части вычислений на вычислительные средства пользователя. В конечном итоге это привело к появлению так называемых клиент-серверных вычислений, где клиент и сервер связаны так, что обработка данных и хранение информации распределены между ними. За термином «клиент» при этом скрывается компьютер пользователя, а термином «сервер» обозначается некоторый (например, расположенный в «вычислительном центре») компьютер, обеспечивающий необходимые
Клиент-серверные конфигурации
РаспределенноеУдаленноеРаспределеннаяУдаленноеРаспределенная
представление представление функцияуправлениеБД
данными
Рис. 2*2.Источник: Gartner Group
вычислительные ресурсы, ПО или данные. Схема различных типов клиент-серверных вычислений приведена на рис. 2.1.
Термины «тонкий» и «толстый» клиент в целом характеризуют возможности обработки данных на стороне клиента. «Тонкость» и «толстота» в сочетании друг с другом с увеличением технологических возможностей постоянно меняются. Альтернативными терминами, возможно с несколько иными оттенками значений, являются термины «слабый» и «мощный». Обычно «тонким» (или слабым) называют клиента со сравнительно небольшими возможностями обработки данных. При этом большая часть обработки данных в среде тонкого клиента возложена на сервер. Соответственно, «толстым» (или мощным) называют клиента с большими вычислительными возможностями.
Трехзвенная клиент-серверная архитектура, которая часто используется для обработки данных на предприятии, включает три сервера (или три группы серверов), которые выполняют разные задачи. Один работает с прикладным ПО, другой — с ПО баз данных, третий обеспечивает интерфейс с пользователем. Дополнительно могут также использоваться серверы, обеспечивающие поддержку сервисов, осуществляемых серверами приложений. Эти вспомогательные серверы могут осуществлять функции управления диалогом, межсетевого обмена и др.
SAP и клиент-серверная архитектура
Первый продукт компании SAP (система R/2, разработанная для использования в среде мейнфреймов) был представлен в 1974 г; Клиент-серверное ПО компании SAP (R/3) было представлено в 1992 г. в Европе и в 1993 г. в Северной Америке.
ПО R/3 может быть сконфигурировано большим числом способов (ASAP 1996). На одной стороне спектра ——применение центральной системы для осуществления представления информации, исполнения приложений и сервисов, связанных с БД. На другой — использование крупными ERP системами трехзвенной архитектуры клиент- сервер с отдельными серверами для каждой из указанных функций (ASAP 1996; Juergens 1999).
Сети
Конфигурация клиент-сервер предполагает связь клиента с сервером с помощью локальной сети или через Интернет. Возможности, стандарты и защита сети имеют первостепенное значение для успешной работы любой системы. В этом разделе дан краткий обзор информации по концепциям сетей, и эта информация будет в дальнейшем использована в книге.
Локальные сети, интранет и экстранет
Локальные сети — это сети, использующиеся для соединения компьютеров между собой в пределах сравнительно небольших географических пространств, например, в пределах одного здания. Глобальные сети соединяют компьютеры на больших расстояниях. Ин- транет-сетями (intranet) обычно называют глобальные сети, предназначенные для использования конкретной корпорацией, а экстранет- сетями (extranet) — глобальные сети, предназначенные для использования, кроме самой корпорации, и ее партнерами.
Пропускная способность, стандарты и защита
Сеть должна соответствовать требованиям, предъявляемым приложениями. Чем больше пропускная способность, тем больше возможности сети.
Стандартные протоколы позволяют передавать информацию в общепринятой форме, способствуя взаимодействию между компонентами. Наиболее распространенными сетевыми стандартами сегодня, наверное, являются стандарты, связанные с Интернетом: про-
токол управления передачей (transmission control protocol (TCP)) и Интернет-протокол (IP).
Одними из многочисленных способов защиты информации являются использование межсетевых экранов и шифрование. Межсетевые экраны обеспечивают мероприятия по защите в сетях. Они усиливают защиту серверов, контролируя трафик. Межсетевые экраны обычно размещают между локальной сетью корпорации и внешней сетью (например, Интернетом).
Шифрование обеспечивает безопасность информации, передаваемой через открытые сети. В частности, путем шифрования информация, которую можно прочесть, преобразуется в нечитаемую форму. При этом информационная безопасность может быть обеспечена путем шифрования данных таким образом, что к ним могут получить доступ только те, кто обладает специальными правами и в силу этого может использовать соответствующие механизмы дешифрирования.
Каналы свнзи, используемые SAP
Если ERP система работает в автономной сети, то пропускная способность данной сети должна быть достаточной для того, чтобы соответствовать потоку деловых операций этой системы. Другими словами, сеть должна адаптироваться и к потоку операций в ERP, и к нагрузке, вызванной работой любых других приложений, использующих ту же самую сеть.
Коммуникации внутри ERP системы обычно базируются на стандартных протоколах связи. Например, система SAP R/3 для организации взаимодействия между клиентом и сервером использует протокол TCP/IP (ASAP 1996).
Два способа защитыг используемых SAP
SAP предлагает несколько способов защиты. В данном разделе говорится о маршрутизаторах SAP и шифровании (см. Juergens 1999).
Маршрутизатор SAP — это ПО, обеспечивающее дополнительный уровень защиты. Оно обеспечивает соединения SAP через межсетевой экран. Маршрутизатор SAP не заменяет межсетевые экраны, а используется в сочетании с ними. Его задача ——запретить или раз-
решить соединения отдельной машины или некоторого подмножества машин. Эти маршрутизаторы могут использоваться, например, для соединения пользователей ERP системы с торговым партнером.
Сетевые взаимодействия SAP не шифрует. Однако для тех организаций или учреждений, которым требуется защита данных, SAP предоставляет возможность шифрования определенных взаимодействий.
Базы данных
Большая часть корпоративного ПО, такого как ERP системы, использует реляционные БД для сбора и обеспечения доступности данных предприятия всем модулям ПО. Однако некоторая часть корпоративного ПО все еще базируется на БД «плоских файлов», которые непосредственно не взаимодействуют друг с другом.
Базы данных《плоских файлов^
«Плоские файлы» ——двумерны (строки и колонки). Их легко использовать, но их возможности в части моделирования корпоративных событий ограничены. БД «плоских файлов» обычно используются в ПО, предназначенном для решения конкретной задачи. Например, система продаж содержит информацию, относящуюся к продавцам, как показано на рис. 2.2. «Плоские файлы» БД не могут непосредственно взаимодействовать с другими «плоскими файлами».
АдресАдресИмяИмяПродавец (№)Продавец (№)Рис. 2.2. Плоский файлРис. 2.2. Плоский файл
Адрес
Адрес
Имя
Имя
Продавец (№)
Продавец (№)
Рис. 2.2. Плоский файл
Рис. 2.2. Плоский файл
Проблема использования «плоских файлов» состоит в том, что может возникнуть избыток информации. Рассмотрим в качестве примера «плоский файл», созданный для сбора данных по продаже товаров. Например, нам нужно найти в БД информацию о том, кто совершил продажу, его адрес, номер карточки социального страхования и т. д. Однако, если тот же самый человек совершит другую продажу, в БД снова будут записаны те же данные, что приведет к избытку информации. Одним из средств устранения избыточной информации является использование реляционных БД, где может быть использован единственный номер ссылки для сбора всей информации о том, кто совершил продажу.
Реляционные базы данных
Реляционная БД ——это набор связанных между собой таблиц (см. рис 2.3). Например, вместо того чтобы фиксировать полный набор данных о покупателе (продавце) для каждого заказа, можно воспользоваться только номером покупателя (продавца). Затем, если нужна более детальная информация, можно найти ее в связанной таблице, используя этот номер.
Реляционные структуры достаточно надежны и могут широко использоваться на предприятии. Например, как показано на рис. 2.4, собрана более подробная информация о продажах, в частности о товарах и их количестве в заказе на закупку. Используя реляционный подход, для каждого наименования товара можно сформировать новую таблицу. В результате отпадает нужда в предварительном плани-
ровании того, сколько наименований товара будет в продаже, и других связанных вещей.
Хранилища данных
Хранилище данных — это «единое место в сетях корпорации, где любой пользователь может получить самые последние эффективно организованные данные» (Radding 1995, с. 57). Хранилища данных —— это большие репозитории данных, которые были оптимизированы для обеспечения быстрого ответа на запросы пользователей. Обычно они содержат данные, собранные за много лет, так что пользователи могут принимать решения, базирующиеся на выявленных при анализе данных тенденциях.
Программное обеспечение
ERP системы — это, в конце концов, программные продукты, и говоря об этих системах, необходимо затронуть такие вопросы, касающиеся ПО, как операционные системы, традиционные системы, готовое ПО, системы управления базами данных (СУБД) и существование различных версий ПО.
Операционные системы
Системы планирования ресурсов предприятий были спроектированы для работы со многими операционными системами, включая системы, базирующиеся на UNIX и Windows NT. Изначально, фактически все крупные внедрения ERP систем были сделаны под UNIX. Од-
нако, как сказано в ASAP (1996) о системе SAP R/3, для представления информации, прикладных задач и БД могут использоваться свои операционные системы.
Традиционное программное обеспечение
Традиционным или унаследованным ПО называют ПО, которое предшествовало внедряемому ныне. Традиционное ПО обычно разрабатывалось самой фирмой для автоматизации своей работы. Чаще всего ——это ПО для мейнфреймов. Чтобы иметь возможность создавать традиционное ПО, фирма должна располагать штатом сотрудников, владеющих навыками системного анализа и способных разрабатывать и внедрять ПО. Обычно традиционное ПО требует значительных затрат на свое содержание, так как его необходимо обновлять в соответствии с новыми организационными нуждами.
Готовое программное обеспечение
Готовое ПО —— это ПО, разработанное для использования во многих организациях. Возможно, самое известное готовое ПО было разработано компанией Microsoft. Сейчас существует большое число готовых программных продуктов, предназначенных для использования на персональных компьютерах, включая такие программы, как MS Word и MS Excel. В последнее время на предприятиях отчетливо видна тенденция к использованию готового ПО, и ERP системы сейчас относят к этой категории продуктов.
Готовое ПО создается с большим набором возможностей. Однако многие из них фактически не используются, поскольку каждая компания выбирает из ряда возможностей только те, что нужны именно ей. Одно из средств удовлетворения нужд конкретного предприятия —— настройка параметров ПО. Доступ к возможностям системы не требует ее обязательного перепрограммирования. Вместо этого для выбора необходимых возможностей часто используется «установка переключателей» ——эквивалент переключателей, включающих и выключающих опции в программах.
В конечном счете, использование готового ПО означает отказ от разработки ПО внутри компании и передачу таких разработок на аутсорсинг (т. е. силами сторонних организаций). Как результат, «купить ERP систему значит больше, чем купить программное обеспечение. Вы покупаете у компании точку зрения» (Langdoc 1998). Выбирая ERP систему, вы передаете большую часть обязанностей по содержанию и развитию своих систем ее производителю. Это значит, что важным критерием выбора ПО может быть дальновидность его производителя.
Система управления базами данных
СУБД — это ПО, разработанное для облегчения использования конкретных структур БД, например, реляционных. СУБД необходимы не только потому, что в них сосредоточены данные, но и потому, что они обеспечивают доступ к данным. Информация в виде отчетов извлекается из БД в результате запросов к ним. Это означает, что СУБД умеют формировать команды запроса данных (они позволяют пользователю задавать вопросы о данных) и снабжены генераторами отчетов, позволяющими создавать отчеты о данных.
Обычно системы класса ERP разрабатываются таким образом, чтобы они могли использовать любую СУБД. Например, система SAP R/3 поддерживает СУБД от Oracle, MS SQL от Microsoft, Sybase, DB2 от IBM и Informix .
В некоторых случаях фирмы ограничивают свой выбор ERP систем теми системами, которые совместимы с существующей у них СУБД. Если это так, можно ожидать, что производители ERP систем будут больше заинтересованы в поддержке их продуктами доминирующих на рынке СУБД. Для справки: в 1997 г. рыночная доля СУБД Oracle составляла 39,2%, IBM — 13,3%, Informix — 5,6%, Sybase — 5,4% и Microsoft — 4,5% (Markoff 1998).
С другой стороны, выбор СУБД зависит от операционной системы. Однако, как заметил Юргенс (Juergens 1999), после внедрения сменить СУБД фактически уже невозможно. Аналогично, возможность модернизации ERP системы будет зависеть от совместимости ее новой версии с определенной СУБД.
СУБД и традиционное ПО изначально рассматривались как независимые друг от друга субъекты. Однако в таких ERP системах, как SAP (Juergens 1999), СУБД интегрирована в саму систему посредством «базисных» компонентов.
‘ Версии программного обеспечения
Готовое ПО выпускается в различных версиях, причем новые версии обычно имеют большие по сравнению со старыми версиями функциональные возможности. Примером тому операционная систе-
ма Windows корпорации Microsoft. Она была выпущена в версиях Windows 3.1, Windows 95, Windows 98, Windows 2000 и Windows NT. A co времени выхода системы SAP R/3 было несколько версий этого программного продукта, включая 3.0, 3.1,4-0, 4.5 и 4.6.
ПО систем планирования ресурсов предприятия выпускается в различных версиях в связи с тем, что происходит добавление новых характеристик, включаемых в него в процессе его развития. Для покупателей ERP систем существуют как преимущества, так и недостатки использования новых версий. Среди преимуществ — наличие новых характеристик и устранение имевшихся дефектов. Среди недостатков ——возможная несовместимость различных версий ПО и затраты на модернизацию.
Выбор программного обеспечения и анализ требований
В данном разделе рассматриваются вопросы выбора ПО и дается анализ требований.
Выбор программного обеспечения: анализ затрат и выгод
Выбор ПО не должен быть случайным процессом, а должен представлять собой результат тщательного учета всех факторов, которые могут повлиять на принятие решения. Кроме того, рациональный выбор, отдающий предпочтение какому-то программному пакету, обычно подразумевает разновидность анализа экономической эффективности или «возврата на инвестиции» (Return on Investment, ROI). К сожалению, выгоды могут быть неявными (трудными для определения и прогнозирования), а некоторые расходы скрытыми. Фактически, расходы и выгоды невозможно полностью измерить, пока система не проработала год или около того. В результате многие попытки анализировать готовое ПО оказываются бесполезными из-за недостатка достоверной информации.
«Как есть» и «Как должно быть»
Существует по крайней мере две модели бизнес-процессов организации: модель «как есть» используется для моделирования теку-
щих процессов, в то время как модель «как должно быть» — для моделирования будущего организации (т. е. тех процессов, которые являются для нее предпочтительными). При выборе ПО организации разрабатывают либо модели своих процессов «как есть», либо модели «как должно быть», либо и те, и другие. И эти модели затем становятся основой для выбора.
Реинжиниринг
Реинжиниринг бизнес-процессов привел к появлению двух различных философий: «лучшие практики» и «ликвидация» (отказ от существующих процессов). В этом разделе объясняется разница между ними.
«Лучшие практики» против «ликвидации^
Реинжиниринг бизнес-процессов, впервые рассмотренный Хэммером (Hammer 1990), предполагал отказ от существующих процессов и создание процессов, которые соответствовали бы нуждам компании в свете передовых технологий. К сожалению, для фирм оказалось трудным отказаться от существующих процессов и работников. Когда же они все-таки решались на это, они не знали, чем нужно заменить существующие процессы или как разработать новые.
Поскольку «лучшие практики» представляли собой процессы, «проверенные жизнью», они быстро нашли признание как средство выбора новых процессов. «Лучшие практики» ——это те, что считаются наилучшими или просто лучшими способами реализации определенного бизнес-процесса.
Одним из источников лучших практик является ERP система. Обычно лучшие практики заложены в библиотеках процессов ERP систем, и при внедрении нужно лишь сделать соответствующий выбор. Как правило, ERP системы содержат множество лучших практик, так что ПО может быть настроено (кастомизировано) для удовлетворения потребностей каждой компании-заказчика, которая устанавливает его. Например, система SAP R/3 содержит более 1 100 лучших практик. Благодаря наличию такого их числа, практически каждая реализация системы является индивидуальной, поскольку набор отобранных лучших практик варьируется от внедрения к внедрению.
Некоторые консалтинговые фирмы имеют свои собственные БД лучших практик, которые используются в качестве альтернативных в процессе поддержки внедрения ERP систем. Например, компания
Price Waterhouse (1995) реализовала свою базу знаний лучших практик «Обзор знаний» («Knowledge View»). Подобные БД лучших практик являются частью того, что все чаще называют «управлением знаниями».
Резюме
В этой главе приведены некоторые вводные данные по информационным технологиям (клиент-серверные вычисления в сравнении с вычислениями, базирующимися на мейнфрейме), сетям (пропускная способность, стандарты и защита), БД («плоские файлы» против реляционных), ПО (операционные системы, традиционное ПО, СУБД и версии ПО), выбору ПО (анализ экономической эффективности и «как есть» и «как должно быть») и реинжинирингу (лучшие практики против отказа от существующих процессов).
Литература
ASAP [World Consultancy] (1996). Using SAP R/3. Indianapolis, IN: Que.
Frye, C. (1994). «With Financial Apps, DBMS Support Often Drives the Sale».
Software Magazine, June, pp. 55-7.
Hammer, M. (1997). «Reengineering Work: Don't Automate, Obliterate». Harvard
Business Review, July/August, pp. 104-12.
Juergens, M. (1999). «Technical Infrastructure». Unpublished presentation, University of Southern California.
Longdoc, S. (1998). «ERP Reality Check for Scared CIOs». PC Week, September 21, p. 88.
Markoff, J, (1998). «Oracle Database lakes Aim at Windows». New Vbrk Times, November 16, p. C5.
Price Waterhouse (1995). Welcome to Knowledge View. Dallas, TX: Price Waterhouse.
Radding, A. (1995). «Building a Better Data Warehouse». InfoWorld, November 20, pp. 57-62.
Часть вторая
ERP СИСТЕМЫ
ОСНОВЫ ERP СИСТЕМ
Цель данной главы ——дать некоторую базовую информацию о ERP системах. Соответственно, мы обратимся к следующим вопросам:
Что такое ERP система?
Кто производит ERP системы?
Кто является партнерами производителей ERP систем?
Что собой представляют некоторые типовые модули ERP систем?
Что значит, когда говорят «лучшие из подобных»?
Что такое дополнения к ERP системам?
Что такое модели, объекты и процессы ERP систем?
Как работают ERP системы?
Так как компания SAP сегодня доминирует на рынке ERP систем, я использую ее систему для иллюстрации некоторых общих понятий, связанных с ERP системами.
Что такое ERP система?
ERP системы — это компьютерные системы, созданные для обработки деловых операций организации и для содействия комплексному и оперативному (в режиме реального времени) планированию, производству и обслуживанию клиентов. В частности, ERP системы имеют следующие характеристики:
это готовое ПО, разработанное для среды клиент-сервер, как традиционной, так и базирующейся на интернет-технологиях;
эти системы интегрируют большинство бизнес-процессов;
они обрабатывают большую часть деловых операций организации;
эти системы используют БД всего предприятия, каждый образец данных в которой запоминается, как правило, единожды;
они обеспечивают доступ к данным в режиме реального времени;
в некоторых случаях данные системы позволяют интегрировать обработку деловых операций и действий по планированию (например, производственное планирование).
Более того, ERP системы все чаще имеют такие дополнительные характеристики, как:
поддержка многочисленных валют и языков (что очень важно для транснациональных компаний);
поддержка конкретных отраслей (например, SAP поддерживает большое число отраслей, включая нефтяную и газовую отрасли, здравоохранение, химическую промышленность и банковское дело);
способность к настройке (кастомизации) без программирования (например, установкой «переключателей»).
Кто производит ERP системы?
Часто ведущих производителей ERP систем обобщенно называют BOPSE по первым буквам названий компаний (BAAN , Oracle, PeopleSoft, SAP и J.D. Edwards). Среди других фирм, производя-
щих ERP системы, такие как Great Plains, Lawson, Platinum, QAD и Ross and Solomon (см., например, Keeling 1996; Kernsarand May 1999). Для дополнительной информации см. PricewaterhouseCoopers 1998.
BAAN (www.baan.com)
Компания BAAN была основана в 1978 г. в Нидерландах. Ее доля на рынке ERP систем составляет примерно 5% (Stein 1997), а доход 1998 г. был равен примерно 750 млн. долларов (Bylinsky 1999). BAAN имеет около 3 000 клиентов в 5 000 населенных пунктов по всему миру. Компания стала известной среди американских производителей ERP систем в 1994 г., когда выиграла конкурс на поставку ERP системы для компании Boeing. Основатели компании недавно ушли из нее отчасти из-за нарушений с финансовой отчетностью, которые привели к завышению данных об объемах продаж (Maremont and Rose 1998).
Oracle (www.oracle.com)
Oracle — второй по величине поставщик ПО в мире. Однако эта компания, возможно, больше известна благодаря своей СУБД, а не ERP приложениям. Компания Oracle была создана в 1977 г в Соединенных Штатах. Приложения для рынка США были разработаны ею в 1989 г., а для международного рынка в 1993 г. В 1997 г. Oracle объявила о том, что она собирается работать на рынке конкретных отраслей (Greenberg 1997а) и улучшить характеристики своего ПО для международного рынка (Greenberg 1997b). В 1997 г. доля Oracle на рынке ERP систем составила 10% (см. Herrera 1999), а ее доходы от продажи ERP систем в 1998 г. составили 2,4 млрд, долларов. (Bylinsky 1999). Как сообщается (Keeling 1996), система Oracle может обеспечить работу более 1 000 пользователей.
Oracle часто критиковали за то, что она разрабатывает БД, а не приложения. Однако, как заметили Керснар и Мей (Kersnar and May 1999, с. 44): «Достижения компании Oracle в производстве баз данных делают ее предложения особенно привлекательными для фирм, которые во многом полагаются на свои собственные базы данных для достижения конкурентного преимущества». На рынке ERP систем Oracle имеет репутацию компании, разрабатывающей продукт, который мо-
жет быть связан с другими продуктами для создания системы, способной претендовать на титул «лучшая из подобных». Oracle также позволяет создавать «доморощенное» ПО (Holt 1998). Кроме того, возможно из-за того, что она в основном специализируется на СУБД, эта компания была первой, предложившей такой продукт, как хранилище данных, и начавшей интегрировать в свои продукты Интернет.
PeopleSoft (www.peoplesoft. сот)
Компания PeopleSoft была основана в 1987 г. и приобрела широкую известность в 1992 г PeopleSoft — третья по величине компания —производитель ERP систем. В 1997 г. ее доля на рынке составила 6%, а прибыль компании в 1998 г. превысила 1,3 млрд, долларов (Bylinsky 1999). Система PeopleSoft может обеспечить работу от 10 до 500 пользователей (Keeling 1996).
ERP система PeopleSoft стала известной из-за предоставления широчайших возможностей планирования человеческих ресурсов (Kersnarand Мау 1999). Во многих случаях фирмы выбирали какую-то иную ERP систему из-за всех остальных модулей (например, SAP) и PeopleSoft для планирования человеческих ресурсов. В некоторых случаях благодаря качеству соответствующего модуля некоторые клиенты выбирали и ERP систему этой компании целиком.
SAP (www.sap.com)
Наибольшая доля рынка ERP систем, составляющая от 30% до 60%, — у компании SAP (Systems, Applications, and Products in Data Processing). В 1997 г. SAP имела долю на рынке 33% (Stein 1997) и поставляла 60% ПО ERP, использовавшегося транснациональными компаниями (Bowley 1998). В 1998 г. доля SAP на рынке увеличилась до 36% (Herrera 1999). SAP ——четвертая по величине фирма — поставщик ПО, уступающая только таким компаниям, как Microsoft, Oracle и Computer Associates International. SAP была основана в 1972 г. в г. Вол- дорф, (ермания. Еще ни одна компания, основанная за пределами Соединенных Штатов, не имела такого успеха (Edmundson, Baker, and Cortese 1997).
SAP известна тем, что тратит большую часть своих доходов (обычно от 20% до 25%) на исследования и развитие. По имеющимся данным система SAP R/3 имеет более 9 000 внедрений в более чем
6 000 компаниях при более чем 2 500 000 пользователей. В 1997 г. доходы SAP превысили 5 млрд, долларов (Bylinsky 1999). Килинг (Keeling 1996) сообщает, что система R/3 может обеспечить одновременную работу от 25 до 1 000 пользователей.
SAP известна, как компания, работающая с фирмами, в которых она заинтересована, и полностью перепрограммирующая их системы для интеграции с R/3 (см. Holt 1998). SAP занимает лидирующее или одно из лидирующих мест среди компаний BOPSE в развитии новых характеристик или возможностей ERP систем. Например, она была первой компанией, разрабатывающей версии своего ПО для конкретных отраслей, и первой действительно международной компанией. Кроме того, она первенствовала в разработке хранилищ данных.
J.D. Edwards (www.jdedwards.com)
Компания J.D. Edwards недавно выпустила свою многоплатформенную систему OneWorld, разработанную для замены выпущенного ранее продукта для системы AS/400 (см. Keeling 1996). Изначально J.D. Edwards была ведущим поставщиком приложений для AS/400. Система OneWorld сейчас доступна для операционных систем Windows NT, UNIX и AS/400. OneWorld была переписана в 32-битной технологии для Windows NT и Windows 95. OneWorld разработана для числа пользователей от 5 до 500. В 1997 г. компании J.D. Edwards принадлежало около 7% рынка ERP систем (Stein 1997). В 1998 г. ее доход от ERP систем составил 979 млн. долларов.
Кто является партнерами производителей ERP систем?
Фирмы, производящие системы планирования ресурсов предприятий, не внедряют все проданное ими ПО. Для его внедрения они обычно работают с большим количеством партнеров (хотя это также приводит к возникновению некоторых проблем, см. March and Garvin 1996). Например, компания SAP работает с четырьмя типами партнеров: «альянсными» (фирмами, оказывающими профессиональные услуги *), «платформенными» (производителями оборудования), «технологическими» (производителями операционных систем и СУБД) и «дополнительными» (производителями инструментальных средств, работающих с R/3). Подход, использованный SAP (а вслед
за ней и другими производителями ERP систем), предполагает распределение большей части прибыли от внедрения ERP систем между партнерами. Для обеспечения доли на рынке в Европе планировалось распределить с партнерами по внедрению 80% доходов, а в Северной Америке — 90% (March and Garvin 1996).
«Альянсные» партнеры ——наиболее интересный случай, поскольку они указывают на быстрый рост числа консультантов. Кей (Кау 1996) отмечает, что в фирме Andersen Consulting работает наибольшее число консультантов ——3 200 человек, в SAP —— 2 800 человек, в Pricewaterhouse — 1 800, в Deloitte & Touche — 1 400. К 1998 匚 число консультантов, работающих на SAP, значительно возросло. Например, как отмечается в Public Accounting Report (1998), в Deloitte & Touche работали более 4 000 консультантов компании SAP, почти втрое больше, чем в 1996 г. Наконец, в середине 1999 г. журнал Forbes (Herrera 1999) сообщил, что в деятельности компании SAP задействовано более 50 000 консультантов, из которых 10% работают в самой SAR
В настоящий момент среди партнеров компании SAP —— такие фирмы, как Andersen Consulting, Cap Genimi, CSC, Deloitte & Touche Consulting, EDS, Ernst & Young, Hewlett-Packard, IBM, KPMG, PricewaterhouseCoopers, Siemens Nixdorf и другие. В Public Accounting Report (1998) отмечается, что «обслуживание пакетов прикладного программного обеспечения таких компаний, как SAP, Oracle, PeopleSoft, BAAN и Lawson, приносят от одной трети до половины общего дохода от консалтинга» фирм «большой пятерки», оказывающих профессиональные услуги.
Консультанты SAP вообще рассматривались по-другому, чем консультанты консалтинговых фирм, сотрудничающих с SAR Например, как отмечают Марч и Гарвин (March and Garvin 1996, с.7):
«Нет ничего из того, что мы делаем, чего не могли бы сделать наши партнеры. Но наши консультанты имеют столь же глубокие знания, сколь их ——широкие. Наши консультанты глубоко знают продукт и всегда будут немного опережать партнеров по своим способностям и требованиям, предъявляемым к ним».
SAP — не единственный производитель, широко сотрудничающий с консалтинговыми фирмами. Например, как отмечается в Public Accounting Report (1997), каждая фирма профессиональных услуг — участница «большой шестерки» (на сегодняшний день «большой пятерки») имеет консультантов, специализирующихся на программных продуктах BAAN и других пакетах.
Что собой представляют некоторые типовые модулиERP систем?
Системы планирования ресурсов предприятий могут обеспечивать большое разнообразие функциональности, используя компоненты, которые часто называются «модулями». Однако различные пакеты включают различные модули, названия которых также варьируются.
Модули SAP
Система SAP R/3 содержит следующие прикладные модули (см., например, ASAP 1996, с. 74-8):
AM (fixed asset management ——«Управление основными средствами»), отвечающий за информацию относительно износа, страхования, основных фондов и т. д.
СО (controlling ——«Управление»), включающий блоки «Учет центров затрат», «Управление себестоимостью» и «Функционально-стоимостной анализ» (activity-based costing, ABC).
Fl (financial accounting ——«Финансы»), включающий блоки «Главная книга», «Дебиторская задолженность», «Кредиторская задолженность» и «Консолидация в соответствии с законодательством» (legal consolidations).
HR (human resources ——«Кадры»), включающий блоки «Управление персоналом» и «Планирование и развитие».
ММ (materials management ——«Управление материалами»), включающий блоки «Управление запасами», «Контроль счетов- фактур», «Управление складами».
PM (plant maintenance ——«Обслуживание предприятия»), включающий блоки «Производственные и технические объекты», «Профилактическое обслуживание», «Управление техническим обслуживанием», «Управление заказами на техническое обслуживание».
РР (production planning — «Производственное планирование»), включающий блоки «Операционное планирование и планирование продаж», «Материальное планирование» и «Планирование мощностей».
PS (project system — «Проектная система»), который включает блоки «Управление проектами» и «Управление бюджетом».
QM (quality management ——«Управление качеством»), включающий блоки «Сертификаты качества», «Инспектирование», «Средства планирования» и «Уведомление о качестве».
SD (sales and distribution ——«Продажи и дистрибуция»).
Кроме того, в системе существуют так называемые «общие» (cross-application) модули, которые могут быть использованы в системе R/3 повсеместно. Среди них — SAP business workflow (поддержка рабочих процессов) и SAP office (поддержка офисной работы).
Приложения компании Oracle
Основные приложения компании Oracle делятся на три специфические группы: «Спрос», «Поставки» и «Финансы». Блок «Спрос» включает модули «Заказы», «Дебиторские задолженности» и «Запасы». В блок «Поставки» входят модули «Проектирование процессов», «Ведомость материалов», «Материальное планирование», «Незавершенное производство» и «Закупки». Блок «Финансы» включает модули «Главная книга», «Кредиторские задолженности» и «Управление стоимостью».
Существуют дополнительные, «наращивающие» приложения. Так, блок «Спрос» может также включать приложения «Комиссионные с продаж» и «Компенсации, связанные с коммерческой деятельностью». Блок «Поставки» — приложения «Планирование цепочки поставок», «График поставщиков», «Производительность и качество». Блок «Финансы» ——приложения «Основные средства», «Проектный учет» и «Финансовый анализатор». Наконец, другие приложения включают модули: «Кадры», «Платежная ведомость», «Хранилище данных» и «Специализированные отчеты».
Что значит «Лучшие из подобных»?
Обычно фирмы выбирают для внедрения единственный программный пакет ERR Однако некоторые из них выбирают подход «лучшие из подобных», пытаясь сочетать и совмещать модули, которые наиболее отвечают их потребностям.
Взаимозаменяемость
Различные модули ERP систем не являются взаимозаменяемыми. Более того, для большинства фирм BOPSE существует мало стимулов делать свое ПО взаимозаменяемым с ПО других фирм, не входящих в этот «клуб грандов». Кроме того, для большинства наиболее
влиятельных фирм, входящих в BOPSE, еще меньше стимулов делать свое ПО взаимозаменяемым с ПО фирм, имеющих меньшее влияние в этом «клубе». В результате мы вряд ли увидим в ближайшем будущем взаимозаменяемые модули ERP систем.
Лучшие из подобных
Хотя, как сказано, модули систем разных производителей не являются прямо взаимозаменяемыми, существуют ситуации, когда фирмы, тем не менее, могли бы попробовать использовать в качестве альтернативы подход «лучшие из подобных». Во-первых, может существовать доминирующая в отрасли ERP система, в которой отсутствует какой-то ключевой набор характеристик, который можно было бы обеспечить альтернативной частью ПО. Во-вторых, могут существовать множество подразделений с во многом одинаковыми, но и в некоторой части различающимися потребностями. В таком случае базовая ERP система может быть адаптирована для всех, а индивидуальные нужды отдельных подразделений могут быть удовлетворены дополнительным ПО. В-третьих, если ни одна из ERP систем не удовлетворяет требованиям фирмы, подходящее решение все же может быть найдено путем сочетания и совмещения различного ПО.
Преимущества и недостатки подхода«лучшие из подобных^
Подход «лучшие из подобных» имеет одно главное достоинство: в идеале фирма получит необходимую ей систему и функциональные возможности в виде неоднородной системы. Однако, скорее всего, потребуются следующие дополнительные затраты. Во-первых, затраты на поиски решения при подходе «лучшие из подобных» обычно больше, так как нужно рассмотреть все модули, которые могли бы удовлетворить нужды фирмы. Во-вторых, «впечатления и ощущения» от использования модулей могут различаться, что может иметь результатом необходимость расширенного обучения или перепрограммирования либо «перепакетирования» В-третьих, различные модули необходимо будет соединить между собой, что может потребовать значительных затрат. В-четвертых1 при подходе «лучшие из подобных» вероятно потребуется команда, обладающая разносторонними зна- нмямм； причем взгляды ее членов на внедрение системы вряд ли окажутся одинаковыми. В-пятых, новые версии ERP систем появляются каждые два-пять лет. В силу этого, с системой, собранной по принципу «лучшие из подобных», могут возникнуть проблемы, связанные с несогласованным во времени появлением новых версий различных
модулей. В-шестых, если различные отделения фирмы используют разные решения в рамках подхода «лучшие из подобных», то единообразия между их системами не будет, а, значит, не будет обеспечено одно из главных преимуществ ERP систем. К сожалению, как заметил Фиман (Freeman 1997, с. 61), во многих случаях «затраты на стыковку специализированного «производственного» ПО с интегрированной ERP системой намного перевешивают преимущества».
Дополнения к ERP системам
Для каждой ERP системы разные производители разработали различные дополнения — дополнительное ПО, расширяющее их возможности. Например, компания SAP поощряла создание различными независимыми разработчиками ПО, стыкуемого с ее ERP системой. Такое ПО увеличивает функциональные возможности SAP R/3 и позволяет понять, какие новые и старые функциональные возможности представляют интерес.
Некоторые технологии, о которых не рассказывается в этой книге, в том числе программы обеспечения связи приложений (applica-
| Кор门叩атмвная「рус口а助弋、|
Рис. 3.1 Модель организационных структур системы R/3 (Источник: SAP)
tion link enabling, ALE), связывания и встраивания объектов (object linking and embedding, OLE) и удаленного вызова функций (remote function calls, RFCs), делают такую стыковку возможной. При этом для разрабатываемого ПО в некоторых случаях применяются аттестационные программы. Например, компания SAP сертифицирует то, что она называет «дополнительными» решениями, некоторые из которых рассматриваются в ASAP (1996).
Модели, объекты и процессы (МОПы) ERP систем
Конфигурировать ERP систему — значит выбрать модели, объекты и процессы (МОПы), которые заложены в системе и используются организацией.
Модели
В ERP системах заложено несколько моделей, таких как, например, модель организационных структур в системе SAP R/3 (рис. 3.1). Эти модели ——отображение реального мира в системе, и их качество важно для отражения реальности. Например, модель организационных структур позволяет фиксировать информацию вплоть до буферного накопителя. И информация может быть объединена, начиная с буфера памяти, до уровня корпоративной группы.
Такие возможности дают не только пользу, но и требуют затрат. С одной стороны, они могут обеспечить системе определенный уровень детализации организации, необходимый для моделирования фирмы. С другой стороны, если модель фирмы меняется, она должна быть изменена и в системе. В результате, если модели меняются часто, это обходится довольно дорого.
Существуют определенные предположения, касающиеся тех основных моделей, которые должны быть адаптированы при внедрении. Например, как указано в приложении к главе 9, организационная модель системы R/3 потребовала от компании Microsoft описать каждое подразделение для целей моделирования оценки либо как центр затрат, либо как центр прибы^1. К сожалению, это представление отличалось от существующей организационной модели, и Microsoft пришлось приспосабливаться к модели.
Объекты
Саймон (Simon 1985, с.10) определил объект как «интерфейс ... между «внутренней» средой ——содержанием и организацией самого
объекта — и «внешней» средой — окружением, в котором он функционирует». Внутренняя среда ——это компьютерная программа, а внешняя — это мир, в котором функционирует система.
Объекты предприятия — пища для информационных процессов. Например, под таким объектом предприятия, как «документ», обычно понимается счет. Кроме того, объектами также являются реализации моделей (в форме перечня счетов, списков производителей, списков продукции и т. д.). Объекты предприятия известные как документы генерируются системами в качестве выходных данных (например, счета) или используются ими в качестве входных данных (заказы клиентов). Объекты предприятия, являющиеся реализациями моделей (например, списки производителей), обеспечивают структуру производственных систем.
Процессы
Процессы — это потоки деятельности и информации, необходимые для выполнения определенной задачи или группы задач. Обычно организации должны выбирать процессы, соответствующие их потребностям, из набора процессов, содержащихся в ERP системе. Поскольку, в принципе, существует множество способов выполнения задачи или групп задач, каждый из процессов не является единственно возможным. А так как они не являются единственно возможными, ожидается, что одни процессы будут работать лучше, чем другие. В рамках ERP систем существуют многочисленные процессы, охватывающие несколько функций.
На рисунке 3.2 изображен процесс управления заказами SAP (McAfee and Upton 1997). Этот процесс отображается в многочисленных модулях SAP, интегрированных между собой. В традиционной функционально-ориентированной системе, напротив, существовало бы, по меньшей мере, четыре различные системы (товарооборот и распределение, производственное планирование, управление материалами и финансы), которые не были бы интегрированы. И обмен информацией между ними производился бы вручную, если бы вообще производился.
Внедрение процессов системами планирования ресурсов предприятий, в конечном счете, требует многих решений, которые обычно принимаются группой внедрения. Среди этих решений такие, как, например, кому выдать кредит и кому отказать, или, когда предложить скидки и кто их должен получить. Коч (Koch 1999) цитирует одного из членов группы внедрения ERP системы: «Мы практически управляем компанией. Мы принимаем решения. Еще два года назад
zstloduzstloduф^хфковасф^хфковасгахзфафсгахзфафсHMTWdAJHeHOXHMTWdAJHeHOXEiWsdx BxdsmoduEiWsdx BxdsmoduBxmeLOOBBxmeLOOBE星。 ФНТФ^2^О§E星。 ФНТФ^2^О§>™фхф^-①SHShAHOU>™фхф^-①SHShAHOUdVS 3S0&SU quAbo5dVS 3S0&SU quAbo5Продажия распределениеПродажия распределениеПродажии рас叩еделен%еПродажии рас叩еделен%еПродажии распределениеПродажии распределениеПроизводственноепланированиеПроизводственноепланированиеУправлениематериаламиУправлениематериаламиФинансыФинансыФинансыФинансы
zstlodu
zstlodu
ф^хфковас
ф^хфковас
гахзфафс
гахзфафс
HMTWdAJHeHOX
HMTWdAJHeHOX
EiWsdx Bxdsmodu
EiWsdx Bxdsmodu
BxmeLOOB
BxmeLOOB
E星。 ФНТФ^2^О§
E星。 ФНТФ^2^О§
>™фхф^-①SHShAHOU
>™фхф^-①SHShAHOU
dVS 3S0&SU quAbo5
dVS 3S0&SU quAbo5
Продажия распределение
Продажия распределение
Продажии рас叩еделен%е
Продажии рас叩еделен%е
Продажии распределение
Продажии распределение
Производственноепланирование
Производственноепланирование
Управлениематериалами
Управлениематериалами
Финансы
Финансы
Финансы
Финансы
Рис. 3.2 Процесс управления заказами.
было бы неслыханно, чтобы те, кто занимает подобные должности, принимали бы такие решения, но сейчас люди хотят, чтобы мы управляли их подразделениями».
Как работают ERP системы?
Чтобы составить общее представление о работе ERP систем, рассмотрим систему компании SAR Прекрасный пример находим у Эдмондсона и др. (Edmondson1997), который мы здесь и приводим. International Sneaker Company (ISC) — это некая гипотетическая американская компания, ведущая торговлю во всем мире; свой продукт она производит в Тайване.
Заказ. Торговый представитель компании ISC принимает заказ от розничного торговца в Бразилии. Вводя данные в свой персональный компьютер, этот представитель получает доступ к модулю продаж системы R/3. Система проверяет цену и скидки для данного розничного торговца, а также его кредитную историю, чтобы убедиться в том, что фирма готова совершить продажу.
Наличие. Затем ПО проверяет наличие товара. Оно находит, что половина заказа есть в наличии на складе в Бразилии, и эта часть заказа может быть реализована немедленно. Сис-
тема R/3 выясняет также, что другую половину заказа нужно будет доставить с предприятия компании ISC.
Производство. Система R/3 уведомляет склад о том, что необходимо доставить розничному торговцу часть его заказа. Кроме того, «производственное» ПО системы R/3 планирует изготовление остальной части заказа. Счет распечатывается в Португалии.
Рабочая сила. Во время планирования производства система R/3 отмечает недостаток рабочей силы для выполнения заказа. Она уведомляет менеджера по персоналу о необходи ■ мости нанять временных рабочих.
Закупка. Модуль материального планирования системы R/3 оповещает менеджера по закупкам, что пришло время заказать новое сыр^5 а также указывает его необходимое количество.
Отслеживание выполнения заказа и последующие заказы. Бразильский розничный торговец входит в систему R/3 компании ISC через Интернет и видит, что часть заказа была выполнена. Кроме того, он может при этом сделать следующий заказ.
Резюме
В данной главе мы рассказали о производителях ERP систем и о самих системах для того, чтобы облегчить понимание материала последующих глав и дать общее представление об индустрии ERP систем. Были рассмотрены партнерские отношения между производителями ERP систем и консультантами, а также другими партнерами. На примере систем SAP и Oracle были представлены сведения о модулях систем планирования ресурсов предприятия, а также определены понятия моделей, объектов и процессов ERP систем. И, наконец, был рассмотрен пример использования ERP системы (SAP).
Литература
ASAP [World Consultancy] (1996). Using SAP R/3. Indianapolis, IN: Que.
Bowley, G. (1998). «Silicon Valley's Transplanted Sapling». Financial Times, March 27. Bylinsky, G. (1999). «The Challenges Move In on ERP». Fortune, November 22. Edmondson, G., Baker, S., and Cortese, A. (1997). «Silicon Valley on the Rhine».
BusinessWeek, Novembers, pp. 162-6.
Freeman, Е. (1997). «ERP Recipe?» Datamation, August, pp. 61-4.
Greenberg, I. (1997a). «Oracle, PeopleSottTargetC/SApps Vertically». InfoWorld, January 13, p. 10.
Greenberg, I. (1997b). «Oracle's App Upgrades Aim at Multinationals». InfoWorld, April 14, p. 14.
Herrera, S. (1999). «Paradise Lost». Forbes Global, February 8, (forbes.com)
Holt, S. (1998). «PeopleSoft Hops on Front Office Band Wagon». InfoWorld, August 31, p. 16.
Kay, E. (1996). «Desperately Seeking SAP Support». Datamation, February, pp. 42-5.
Keeling, D. (1996). «А Buyer's Guide to High End Accounting Systems». Journal of Accountancy, December; pp. 43-52.
Kersnar, K., and May, M. (1999). «Plug and Pray». CFO Europe, June, pp. 40-50.
Koch, C. (1999). «The Most Important Team in History». CIO Magazine, October 15.
March, A., and Garvin, D. (1996). «SAP America». Report no. 9-397-057, Harvard Business School, Cambridge, MA.
Maremont, M., and Rose, M. (1998). «Dutch Software Firm Has Extensive Links to Founder's interests». Wall Street Journal, July 7, p.AI.
McAfee, A., and Upton, D. (1997). «Vandelay Industries». Report no. 9-697-037 Harvard Business School, Cambridge, MA.
PricewaterhouseCoopers (1999). Technology Forecast, 1999. Menlo Park, CA: PricewaterhouseCoopers.
Public Accounting Report (1997). «D&T Allocates 200 Consultants to BAAN Launch». February 28, p. 3.
Public Accounting Report (1998). «Big Six Dominate Systems Integration Market».
July 31, p. 4.
Simon, H. (1985). The Sciences of the Artificial. Cambridge, MA: MIT Press. Stein, T. (1997). «SAP's Fast Track». Information Week, September 1, pp. 14-16.
Приложение 3-1
Geneva Steel: изменение работы бизнеса
Джозеф Кеннон, председатель правления предприятия Geneva Steel, понимал, что предприятию необходимо изменить культуру для изменения его работы в целом .
* Джозеф Кеннон цитируется по материалам интервью, проведенного Эриком Денной (октябрь 1998 г.) и представленного на конференции Technology Visioning 19 ноября 1998 匚(прим, автора).
Мы приняли решение работать с системой SAP. Мы могли принять это решение по многим причинам, но, возможно, главная из них заключается в том, что один из способов, которым вы можете изменить (корпоративную — прим, ред.) культуру, состоит в том, чтобы начать управлять потоками информации, доступностью информации, тем, кто что может знать, сколько может знать и о чем...
И мы подумали: «Как нам изменить... традиционную культуру нашего предприятия и сделать его похожим на небольшое предприятие с меньшей иерархией и большим потоком информации, где будет меньше опасений и больше командной работы?»
Как это сделать? Конечно, ... нет панацеи от всех бед. Одной из причин в любом случае была та, что мы нуждались в замене своих систем ...У нас действительно была устаревшая и примитивная бухгалтерская система, ее нужно было менять.
SAP в сталелитейном производстве
К 1999 г система планирования ресурсов предприятий SAP R/3 была успешно внедрена несколькими фирмами сталелитейного производства. Для Geneva Steel сигналом было то, что в 1995-1996 it швейцарская фирма Kindlimann AG внедрила SAP R/3 (версию 2.2), используя модули финансового учета и управления (FI/СО), логистики с системами продаж и дистрибуции и управления запасами (SD/MM), а также управления персоналом и основными средствами (HR/АМ). В то время член правления компании Kindlimann сказал*:
Внедрение системы SAP было для нас стратегическим шагом для сохранения в будущем лидирующего положения на рынке. Конкурентоспособность все больше зависит от информационных технологий, которые прямо влияют на цены, качество и взаимодействие с клиентами. Система SAP в сочетании с энтузиазмом и приверженностью всех наших служащих — это средство оптимизации и координации этих факторов.
Нью Стил (май 1997) сообщает, что компании UV, Hylsa, Bohler, Arbed, Sidmar, Preussag, Thyssen, Krupp-Hoesch, Mannesmann, Hoogovens, Kidlimann и ВНР приобрели ПО SAP R/3. Кроме того, ком-
Kindlimann AG, SAP (без даты) (прим, автора).
пания Acme Steel, как стало известно, в 1998 匚 внедрила SAP для управления счетами, биллинга, планирования и отслеживания заказов, включая использование Интернета при приеме заказов.
Geneva Steel
Подоплека и краткая история^
Geneva Steel, расположенная в городе Виньед, штат Юта,——единственное сталелитейное предприятие к Западу от реки Миссисипи. В 1998 匚 Geneva Steel имела более 2 400 сотрудников. Контингент заказчиков компании изначально располагался в западной и центральной частях Соединенных Штатов. Geneva Steel продает свою продукцию центрам обслуживания и дистрибьюторам, таким как Mannesmann Pipe and Steel. Около трех четвертей объема продаж компании ——это листовая и толстолистовая сталь; остальное ——трубы и рулонная сталь.
Мерная толстолистовая сталь используется в производстве судов, барж и промышленного оборудования. Кроме того, она применяется в строительстве дорог; мостов и зданий.
Во время Второй мировой войны самым крупным строительным проектом правительства США было развитие завода Geneva Steel. Местоположение завода внутри страны было выбрано из-за близости к необходимому сырью, а также в качестве меры предосторожности на случай захвата тихоокеанского побережья или закрытия Панамского канала. Завод был открыт в декабре 1944 匚 и проработал два года в качестве предприятия, принадлежащего государству. Сталь завода Geneva Steel была использована в строительстве более 2 000 судов класса Liberty. Эти суда, рассчитанные на пять лет эксплуатации, использовались для поставки за рубеж еды, одежды и амуниции.
После войны федеральное правительство продало завод с аукциона. Компания U.S. Steel приобрела завод и руководила им более сорока лет. Однако, в начале 1987 匚 завод был закрыт из-за нескольких факторов, в том числе из-за возросшей иностранной конкуренции и увеличившихся затрат на рабочую силу.
В 1987 г. Крис и Джозеф Кенноны управляли приобретением и повторным открытием завода Geneva Steel в качестве собственно-
сти Basic Manufacturing and Technology штата Юта. К январю 1999 匚 председатель правления компании Geneva Steel (Джозеф Кеннон) и ее президент (Роберт Гроу) были собственниками половины предприятия. В таблице 3.1 представлены его операции в 1996- 1998 гг.
Таблица 3.1. Отчеты об операциях компании Geneva Steel
1998
1997
1996
Чистая сумма продаж
720,453
726,669
712,657
Себестоимость реализованной продукции
659,132
665,977
662,058
Валовая прибыль
61,321
60,692
50,350
Затраты на реализацию,
общие и административные расходы
22,116
22,488
24,943
Списанные активы
17,811
Операционный доход (потери)
21,394
38,304
25,729
Другие доходы (расходы)
Процентные и иные доходы
356
413
Затраты на выплату процентов
(42,483)
(40,657)
Прибыль до уплаты подоходного налога
(20,733)
(2,040)
Отчисления на уплату подоходных налогов
(1,790)
(772)
Чистая прибыль (потери)
(18,943)
(11,608)
(16,327)
Примечание: Суммы — в тыс. долларов.
Источник: Пресс-релиз компании за 16 ноября 1998п и 12/97 10-К.
Geneva Steel имела традиционную корпоративную культуру сталелитейного предприятия. По словам Кеннона: «Наша культура была во многом традиционной культурой сталелитейного предприятия. Тэ есть иерархичной культурой, в которой присутствовал страх. Страх перед неудачей, страх перед вышестоящими лицами организации». Компания Jacobson & Associates, исследовавшая вопросы удовлетворения нужд покупателей стали, обнаружила, что Geneva Steel имеет рад проблем в этой области. Как заметил Кеннон: «Мн были полными мертвецами».
Производственный процесс^
Для выплавки стали Geneva Steel использует железную руду, известняк и каменный уголь (см. рис. 3.3). Используя самую широкую из действующих в мире линий непрерывной разливки стали и проката, Geneva Steel может производить стальные листы шириной 126 дюймов. Специальные финишные стенды позволяют раскатывать сталь в соответствии с нуждами покупателя, варьируя ее толщину от
Самая широкая и толстая в мире линия резания и линия уровня листаСамая широкая и толстая в мире линия резания и линия уровня листаРис. 3・3・ Geneva SteelРис. 3・3・ Geneva Steelи толстолистовая стальи толстолистовая стальтрубы рулон-трубы рулон-
Самая широкая и толстая в мире линия резания и линия уровня листа
Самая широкая и толстая в мире линия резания и линия уровня листа
Рис. 3・3・ Geneva Steel
Рис. 3・3・ Geneva Steel
и толстолистовая сталь
и толстолистовая сталь
трубы рулон-
трубы рулон-
1-LMF; 2-литейная машина; 3. буфер горячих слябов; 4. поточное кондиционирование слябов; 5. индукционная печь; 6. печи выравнивания температуры; 7. гидравлическое регулирование кромок и снятие окалины; 8. черновой прокат; 9. резка; 10. полосное снятие ока- лины; 11. непрерывный 6-интервальный раскат; /2 ламинарное поточное охлаждение; 13. с^ртка; 14. размотка; 15. равнение; 16. обрезка кромок; 17. резка; 18. выравнивание толстого проката; 19. выравнивание тонкого проката; 20. наложение проката.
до 0,07 дюйма. Geneva Steel также обладает линией резки и выравнивания листа, используемой для создания самой широкой и толстой в мире продукции этого вида. Производственный процесс на Geneva Steel изображен на рис. 3.3.
«Мини-заводы»*
С 1970 по 1985 г производство стали в США уменьшилось примерно в два раза. В то время как многие большие компании сокращали производство, группа малых сталелитейных компаний удвоила выпуск своей продукции, используя электродуговые печи или «мини-заводы».
К 1991 匚 доля «мини-заводов» в производстве стали США составила 22,7%, в то время как в 1981 г она равнялась 15%. Некоторые эксперты полагают, что в 2000 г «мини-заводы» выпустят 14млн. т го- рячекатанной стали, по сравнению с 3 млн. т в 1995 п
Как отмечает SteelNet:
Рост производства стали с использованием электродуговых печей можно объяснить несколькими факторами, главные из которых — экономическая эффективность и качество. Благодаря низким зкс- плуатационным расходам и использованию гибких эффективных организационных методов, производители стали, использующие такое оборудование, могут повысить доходы и качество продукции.
Информационные системы управлениякомпании Geneva Steel
По мере своего развития конфигурация информационной системы компании Geneva Steel стала включать несколько неоднородных систем, что усложнило интеграцию и доступ к информации. Как сказал Кеннон:
У нас есть ... мейнфрейм ... и ... примитивная бухгалтерская система ...
У нас много различных типов компьютеров. Им сложно общаться друг с другом. У нас большое количество мини-компьютеров различных типов с различным программным обеспечением ... Наша система —это выход из этого ада.
Используемая ныне информационная система порождает большое количество данных о деловых операциях, но данные большинства этих систем, в общем, недоступны. Как заметил Кеннон: «Мы ... порождаем буквально миллионы единиц информации. Но ... они недо- ступны нам и, конечно, не интегрированы между собой».
Информационная система предоставляет три основополагающих ежедневных отчета для поддержки решений, принимаемых Кенноном.
Один из основных отчетов, который я рассматриваю — зто отчет об операциях. В нем приводится список... вполне определенных вещей ... [например] ... количество полос в час. Этот отчет не такой подробный, как отчет о ежедневных операциях (daily operations report, DOR) или ежедневный отчет об операциях (daily report of operations, DRO)…И эти три отчета — не единственные, которые я получаю. Я не говорю об отчетах о продажах... Они идут отдельно... У нас также есть более толстые отчеты по многим другим вопросам, поми-
мо продаж: по бухгалтерии, транспортировке и [другим] операциям. Но те отчеты, о которых я только что упомянул,... — ежедневные отчеты. А еще у нас есть отчеты, которые формируются, по крайней мере, каждую неделю или, может быть, немного чаще ...- отчеты по информации о продажах. Хорошо, что я получаю большую часть отчетов по электронной почте и фактически не имею дела с большим количеством бумаг Но точно ——это отдельные отчеты.
К сожалению, информационная система предоставляет ограниченную информацию о клиентах и их заказах.
Может быть, что-то, чего мы не знаем о расходах на горячий металл, поступающий для конкретного клиента. Я думаю, что мы интуитивно знаем это и, может быть, в некоторых случаях мы это действительно знаем.
Торговым представителям ... трудно вычислить, пце находится заказ.
Кроме того, используемая информационная система ограничивает связи с клиентами. Как сказал Кеннон:
Как [клиенты] ... получают информацию? Как они узнают, конца часть стали прибывает в их распоряжение? Соответствует ли это заказу? Придетли он тогда, конца они его заказывали? Все это — те вещи, которые могут быть улучшены путем расширения коммуникаций с ними и коммуникаций внутри компании.
В используемой ныне информационной системе интеграция информации ——критически важная часть работы менеджеров компании.
Интеграция — по большей части, интеллектуальная. Другими словами,... менеджеры ——это интеграторы. Я рассматриваю продажи, отчеты о ежедневных операциях и ежедневный отчет об операциях. Честно говоря, мы больше используем ежедневный отчет об операциях, однако у нас много и других отчетов... Нона основе ежедневных операций интеграция происходит в голове у человека, и, будем надеяться, у человека, работающего с другими людьми.
Кроме того, [когда] ... мы составляем бизнес-план, ... нам приходится делать усилия, чтобы интегрировать информацию...
В настоящее время различные традиционные системы предполагают наличие персонала, ответственного за «интерфейсный шлюз» ——связующее звено, заботящееся и содействующее взаимодействию между программой и ее пользователями и программой и другими программами. Немногие из традиционных программ умеют общаться с другими. Более того, только ограниченное число людей, занимающихся технологиями, знакомы с конкретными приложениями, и только некоторые бухгалтеры понимают, что делают программы, и какая информация требуется для их использования. Как заметил Кеннон, в сущности «нужно иметь бухгалтера в каждом подразделении».
Проект «Дельта» компании Geneva Steel
В 1997 г. Geneva Steel начала реинжиниринг ——проект «Дельта». Его целью было «произвести систематические и глубокие изменения с учетом корпоративных систем, процессов и структур». Задачей было снизить затраты на 20% по сравнению с 1996 календарным годом. Как сказал Кеннон в пресс-релизе в марте 1997 с:
Наши попытки снизить административные издержки являются только частью большого проекта, названного проектом «Дельта» и направленного на систематические изменения способа, которым мы ведем бизнес в Geneva Steel. В течение последних нескольких месяцев несколько команд начали работать над улучшением всех аспектов деятельности нашей компании, включая услуги клиентам, взаимодействие между служащими и операции. Эти начинания необходимы для того, чтобы оставаться конкурентоспособными на рынке стали. Недавнее резкое повышение импорта стали и растущее производство внутри страны усилили конкуренцию на рынке. В ответ мы осуществляем системные изменения с целью обеспечения нашей долгосрочной конкурентоспособности.
Проект «Дельта» начал порождать ряд изменений.
Организационные изменения
июня 1997 г. Geneva Steel объявила о перераспределении ответственности в управлении между исполнительными директорами. Согласно пресс-релизу компании:
Изменения в нашей структуре управления направлены на сосредоточение наших ресурсов в тех областях, которые могут принести изменения к наибольшим усовершенствованиям в компании ... Изменения в отношении отчетности направлены на то, чтобы отразить приверженность компании к тому, чтобы стать горизонтально направленной организацией, сфокусированной на внедрении стратегического плана.
С сентября 1997 匚 административный и исполнительный штат сотрудников Geneva Steel был сокращен с 328 до 219 человек, а операционный менеджмент — со 155 до 92 человек .
Организационные меры
Чтобы оценить значение изменений по проекту «Дельта», Geneva Steel разработала несколько критериев для обеспечения сбалансированных измерений качества, своевременности и затрат. Первостепенное значение имели следующие показатели:
своевременность поставок;
аккуратность исполнения заказов;
стоимость производства одной тонны продукции;
административные расходы на производство одной тонны продукции;
претензии клиентов;
результаты производства по видам деятельности;
уровни запасов и продукции.
Как сказал Кеннон:
Другим показателем будет удовлетворенность клиентов — как наши клиенты смотрят на нас. Мы не делали этого так, как могли бы или должны были бы делать... Мы стремимся к интеграции с клиентами, и для этого мы проводим некоторые организационные изменения.
SAP
К сожалению, использовавшаяся в Geneva Steel информационная система управления не собирала достаточный объем информации для точного измерения каждого из данных показателей. Кроме
Geneva Steel, декабрь 1998 10-К (прим, автора).
того, традиционные системы ограничивали внедрение новых технологий. В результате, Geneva Steel решила внедрить SAP, чтобы содействовать новым рабочим процессам и сделать возможным сбор информации для набора новых сбалансированных показателей.
Результаты внедрения SAP, ожидаемые Geneva Steel
Как предвидел Джозеф Кеннон, от внедрения SAP R/3 ожидалось множество результатов.
Меньшее количество компьютерного оборудования и ПО
Внедрение SAP выполняется в среде клиент-сервер. Значит, мейнфрейм компании Geneva Steel при внедрении системы использоваться не будет. Кроме того, обычно внедрение SAP везде сокращает использование традиционных приложений с 50% до 90%. И так как SAP ——интегрированное приложение, то станет меньше компьютерного оборудования и ПО, а сама система SAP будет полностью интегрирована.
Возможности отчетности
Кеннон ожидал, что SAP обеспечит более надежные и интегрированные возможности отчетности: «Одним из достоинств SAP является то, что она совмещает все отчеты [о продажах, о ежедневных операциях (DOR) и ежедневный отчет об операциях (DRO)] ... и вам нет необходимости иметь три отдельных отчета».
Доступность информации
Кеннон отметил, что с внедрением SAP должен улучшиться доступ к информации:
Мои ожидания от SAP состоят в том, что вы получаете интегрированный инструмент..., который сам по себе ничего не будет делать, но позволяет иметь больший доступ к информации в более понятной, действенной форме, в форме более удобной для использования.
Кеннон также считал, что SAP сделает информацию (например, о продажах) более доступной и внутри компании, и, в конечном счете, для клиентов: «Если у вас есть номер партии и система, которая ... позволяет связываться с ней, то люди в различных частях организации могут иметь больше информации о том, что их интересует».
Пользователи информации
Кеннон надеялся, что SAP обеспечит более стратегическое использование информации, способствуя задаванию вопросов типа «что если?», и таким образом улучшит процесс принятия решений.
Надеюсь, что [наше использование информации будет] более стратегическим...
Я думаю, что это дает в руки [менеджмента] инструмент/оружие для того, чтобы привести нас в состояние более ранней готовности:... «Вы думали об этом?».
Я думаю, это даст нам большую возможность задавать вопросы «что, если попробовать это?» или «что, если попробовать то?» Я думаю, у нас будет база данных и, задав вопрос «что произошло, когда мы сделали это?», мы сможем обратиться к ней и получить ответ.
Кроме того, Кеннон считал, что возрастет доступ к данным и, как результат, — возможность анализировать взаимосвязи между группами данных:
Данных будет все больше и больше ... Можно будет соотнести две переменные. Вы сможете более точно и прямо соотнести продажу определенного продукта со всеми издержками.
Наконец, Кеннон считал, что SAP обеспечит большие возможности —такие как возможность постановки вопросов,——о которых можно будет узнать и которые понять можно будет до конца только после внедрения системы: «Она предоставит вам большее пространство для игры, чтобы узнать о многих вопросах, о некоторых из которых я еще не знаю, но которые со временем возникнут».
Интеграция информации, осуществляемая системой
Кеннон также считал, что в вопросе интеграции информации уйдет необходимость полагаться на менеджеров, и SAP будет более тесно интегрировать виды деятельности.
Мы будем знать, какова стоимость. Как мы узнаем это? Потому что отдел закупок сделает свою работу. Отдел кадров свою,... и все это будет интегрировано в прозрачную для нас систему. Бухгалтер в каждом конкретном подразделении будет не нужен.
Организационные взаимодействия
в бухгалтерских и информационных системах
Кеннон предполагал, что внедрение SAP приведет к более тесному взаимодействию бухгалтерских и информационных систем и интеграции бухгалтерской деятельности с деятельностью команды менеджеров.
[Я ожидаю], что наши специалисты в области бухгалтерии, наш главный финансовый администратор и управляющий, входящие в эту команду, [будут работать] как единое целое с командой менеджеров... Я ожидаю действительно тесной интеграции бухгалтерских и информационных систем, И что это приведет к созданию структуры для принятия решений.
Кроме того, предполагается, что внедрение SAP повлияет на число бухгалтеров и персонала, сопровождающего информационные системы. Как заметил Кеннон:
В первую очередь, у нас будет меньше бухгалтеров и, возможно, меньше администраторов информационных систем. Потому что одна из вещей, которые мы рассматриваем, это сокращение части этих функций. Когда будет внедрена система SAP, большую часть того, что делают бухгалтеры ... не нужно будет делать.
Как результат, компания Geneva Steel предполагала сократить свой штат сотрудников подразделения информационных технологий примерно с 80 до 12 человек, а штат бухгалтерии — с 60 до 10 человек.
Планирование и информация
Кеннон также считал, что система повлияет на удовлетворенность клиентов и на способность компании планировать: «Другая область влияния системы [SAP] — это то, как мы планируем... Системе производственного процесса очень важно то, как вы планируете снижение выпуска продукции. Это [только] один ее аспект».
Ввод в эксплуатацию системы SAP в Geneva Steel
В декабре 1997 с Geneva Steel объявила о том, что она начинает внедрение системы SAP R/3.
Компания выбрала и начала внедрение ПО SAP — бизнес-сис- темы, охватывающей все предприятие. Компания ожидает больших выгод от данного внедрения, в том числе относительно «Проблемы 2000-го года», связанных с традиционными системами, базирующихся на мейнфреймах. Проект в настоящее время оценивается в сумму от 8 до 10 млн. долларов; внедрение будет закончено к 1999 п Готовится обзор, в котором будут оценены последствия некоторых других воздействий «Проблемы 2000-го года» на процессы управления программами и компьютерным оборудованием. В зависимости от рынка, операций, ликвидности и других факторов, компания может скорректировать структуру, сроки и планируемые затраты основного плана. Кроме того, условия возобновляемого кредита содержат определенные ограничения на капитальные вложения.
В декабре 1998 二 компания Geneva Steel отметила:
Система [SAP] затрагивает практически каждый аспект операций компании. В 1998 финансовом году компания установила новое, учитывающее «Проблему 2000-го года» оборудование компании HP и модули SAP для финансового учета, закупок и учета кредиторской задолженности, сырья, управления запасами и дебиторской задолженности. Компания проводит окончательную интеграцию, тестирование и аттестацию различных других модулей SAP. Ожидается, что модули «Кадры» и «Платежные ведомости» будут внедрены к 1 января 1999 п В начале 1999 с компания также внедрит другие модули SAP, включая модули продаж и дистрибуции, управления запасами, производственного планирования, калькуляции себестоимости продуктов и другие информационные системы управления.
Geneva Steel также отметила, что на 30 сентября 1998 匚 на внедрение SAP она затратила примерно 5 млн. долларов, и что внедрение будет завершено в 1999 匚
Принятие и непринятие системы SAP
Систему SAP приняли не все и не сразу.
Я даже видел, что начинает меняться культура. Очевидно, что были люди ——глубокие противники внедрения системы SAP. «Это слишком дорого», «Это слишком трудно», «Просто покупается новая
игрушка» ... Я слышал подобное и много чего другого от противников внедрения SAP.. Даже сегодня я не думаю, что ситуация полностью изменилась... Я думаю, мы получили критическую массу людей, которые поддерживают нас. И коща смотришь на проводимое здесь обучение, видишь намного больше веры в SAP. И, собственно говоря, люди, наконец, поняли, что, нравится им это или нет, это должно произойти.
Вопросы
Какие проблемы были у Geneva Steel с традиционной системой?
Каковы результаты внедрения SAR ожидаемые Geneva Steel?
Может ли SAP оправдать эти ожидания?
Что вы думаете по поводу показателей, которые Geneva Steel планировала использовать для оценки проекта «Дельта»?
Geneva Steel планирует использовать SAP для изменения своей корпоративной культуры. Каковы достоинства и недостатки такого подхода к изменению корпоративной культуры?
4
ВВОД ДАННЫХ В ERP СИСТЕМАХ
Системы планирования ресурсов предприятий в конечном итоге приводят к реинжинирингу организационных процессов. Например, во многих традиционных системах данные собираются на погрузочной площадке, обрабатываются бухгалтерами и затем вводятся в систему. Однако ERP системы разработаны таким образом, что они могут использоваться с момента создания данных, зачастую прямо при выполнении операций. В результате такого реинжиниринга (см. Hammer 1990) происходят большие изменения в процессах, затрагивающие следующие вопросы: кто собирает данные, как они собираются (фактически, собирается больше данных, минуя оформление на бумаге, и они вводятся непосредственно в компьютерную среду), сбор данных на месте их создания, замена бухгалтеров людьми, собирающими информацию при осуществлении операций, и изменения, при которых данные генерируются так, чтобы акцентировать внимание на процессе.
Каждое из этих системных изменений может иметь большое влияние на сбор данных (например, кто вводит данные, где осуществля-
ется ввод данных, и как часто вводятся собранные данные), и это в конечном итоге влияет на качество данных. Как результат, изменения во вводе данных, осуществленные в процессе реинжиниринга, могут влиять на соответствующие затраты при внедрении ERP системы и выгоды от него.
Оценка выгод зачастую более трудная задача, чем оценка затрат, —возможно, потому что выгоды еще не актуализированы и зачастую являются менее прямыми. Таким образом, чтобы понять вклад выгод, необходимо идентифицировать преимущества, которые ассоциируются с системными изменениями.
С одной стороны, затраты на внедрение, зачастую, можно определить сразу. Но даже в этом случае существуют некоторые затраты, которые трудно измерить. Например, изменения в процедурах ввода данных могут породить недовольство со стороны пользователей. Так как недовольство пользователей может повлиять на стоимость внедрения и потенциальный успех внедрения ERP системы, важно: (а) определить возникающие факторы, которые могут вызвать недовольство пользователей и (б) разработать модель, которая поможет понять последствия, вызванные сложностями внедрения, возникающими из-за ввода данных.
Таблица 4.1 Источники доходов и расходов на ввод данных:последствия реинжиниринга
Однократный сбор данных
Сбор большего количества данных
Ввод данных непосредственно в компьютер
Сбор данных на месте их создания
Сбор данных с акцентом на процессе
Например, так как ERP системы имеют более общий характер, чем традиционные системы, структура экранных форм и ввода данных в ERP системе может привести к более медленному вводу данных в сравнении с традиционными системами, которые зачастую создавались специально для реализации конкретной цели. Время, необходимое для ввода данных в многочисленные экранные формы (окна) ERP систем, может повлиять на количество входных сообщений, которые могут быть обработаны в течение данного промежутка времени. В результате, в тех организациях, ще существуют значимые различия между возможностями традиционных систем и новых ERP систем, такие процессы, как обработка заказов, из-за ввода данных могут протекать значительно медленнее. Более медленная обработка
данных может привести к снижению производительности, повышению затрат на ресурсы и к трудностям при внедрении. Следовательно, важно иметь модель, которая позволит выявить такие трудности. В данной главе представлены две такие модели.
В любом случае недовольство пользователей ERP системами из- за проблем с вводом данных заставили производителей ERP систем уделить больше внимания тому, чтобы сделать эти системы более легкими в использовании. Однако то, как ERP системы были изначально спроектированы и построены, позволяет многим экспертам предполагать, что проблемы с вводом данных будут продолжаться.
Источники выгод и затрат при вводе данных:последствия реинжиниринга
Системы планирования ресурсов предприятий способствуют многим принципам реинжиниринга1 перечисленным Хеммером (Hammer 1990) и другими исследователями. Некоторые из этих принципов в конечном итоге влияют на ввод данных. Хотя реинжиниринг может улучшить организационные процессы, источники выгод могут вызвать недовольство пользователей. Эти источники изменений отражены в таблице 4.1.
Однократный сбор данных
Существует большое число преимуществ однократного сбора данных по сравнению с многократным. Если данные собираются только один раз, расходы обычно меньше. Если данные собираются только один раз, то все пользователи находятся как бы на «одной странице» используемых данных, так что прогнозы и т. п. будут сделаны с использованием тех же данных. Расходы на обновление данных при этом ниже, так как нужно будет обновить только один экземпляр данных.
Системы планирования ресурсов предприятий обычно используют структуру реляционных БД, поэтому если одна часть информации была собрана, снова собирать ее не нужно. Однократный сбор данных гарантирует, что пользователи имеют доступ к одним и тем же данным в одно и то же время, что одни и те же данные используются всей фирмой для планирования и управления. Кроме того, так как данные собираются только один раз, фирмы рассматривают ERP системы как системы, предоставляющие возможность сократить число конторских служащих и соответствующие расходы. Конторские служащие и те,
кто с ними сотрудничает, вероятно, не считают это преимуществом, и возможно недовольство пользователей возрастет.
Основной недостаток однократного сбора данных в следующем: если данные неправильные, это неблагоприятно отразится на всех их пользователях. ERP системы не предполагают избыточности. Следовательно, критически важными являются контроль ввода данных (для проверки их корректности) и организационные карты процессов (индицирующие рабочие функции). Если в систему введены неправильные данные, возможно, никогда не будет обнаружено, что они неправильные. Например, как сказал Коч (Koch 1999):
До ERP систем складские клерки знали, что они могут разрешить грузовику покинуть погрузочную площадку без отметки доставляемых товаров на погрузочном бланке. Бланк будет находиться там, и если клерки забудут о нем, в какой-то момент, те, кто должен был получить счет, позвонят и потребуют этот бланк. Сейчас этого нет. Если клерки не отчитаются за все до того, как грузовик отъедет, покупатель никоща не получит счет, потому что в ERP системе нет отметки о том, что товары доставляют. Получатели счета никогда не узнают, что покупателю товары доставлены, — звонков с напоминаниями больше не будет.
Сбор большего количества данных
Так как все данные находятся в одном месте, связанные вместе в реляционной БД, собирать большее количество данных стало экономически эффективно. В результате, вместо того, чтобы агрегировать данные до их ввода, можно их собирать по отдельности, и система осуществит необходимое агрегирование, когда будут составлены отчеты.
К сожалению, чем больше данных собирается, тем выше стоимость их сбора. Однако выгоды от принятия решений могут перевесить любые дополнительные затраты.
Ввод данных непосредственно в компьютер
Изменяются не только количество данных и то, сколько раз они собираются, но и средства их сбора. Как сказал менеджер проекта по внедрению SAP R/3 компании Purina Mills: «Мы берем людей, которые записывали часть информации на бумаге, и сажаем их за персональные компьютеры» (Stedman 1998b).
Преимущества такого подхода могут быть очень большими, так как больше не существует промежуточного дублирования данных (с бума-
ги на бумагу и в компьютер). Данные заносятся непосредственно в систему. Однако есть и недостатки. Для работников с ограниченным опытом работы с компьютером такие изменения могут оказаться слишком сложными, что может повлиять на успех внедрения. Кроме того, при этом подходе в некоторых случаях менеджерам и другим служащим придется выполнять работу клерков, осуществляющих ввод данных.
Сбор данных на месте их создания
При использовании традиционных систем необходимы различные служащие, которые собирают данные для ввода их в систему. Информация на бумаге доставляется бухгалтерам, которые, в конечном счете, несут ответственность за ввод данных в систему. При использовании ERP системы сбор данных происходит ближе к месту их создания. Как сказал руководитель проекта по внедрению ERP системы компании Purina Mills: «У нас больше, чем когда-либо, людей, вводящих информацию» (Stedman 1998b). В результате, персонал, занимающийся сбором данных, — не бухгалтеры, а люди, занимающиеся выполнением операций. В некоторых компаниях ожидается, что это изменение приведет к сокращению числа бухгалтеров и клерков, как в случае с компанией Geneva Steel, рассмотренном в третьей главе.
Улучшат ли эти изменения качество ввода данных, определит конкуренция. С одной стороны, данные могут стать более точными, потому что, в отличие от традиционных систем, им не нужно проходить через различные уровни организации перед их вводом в систему. Например, при использовании многих традиционных систем данные фиксируются на бумаге на погрузочной площадке, обрабатываются бухгалтерами и затем вводятся в систему. При использовании ERP системы данные обычно собираются на погрузочной площадке и непосредственно передаются в Главную книгу и в финансовые отчеты.
С другой стороны, бухгалтеры выбрали работу, которая связана со сбором данных и передачей информации. А производственный персонал (например, работники погрузочной площадки) во многих случаях не будет заинтересован во вводе данных в ERP систему и не сможет их вводить. В результате персонал, вводящий данные, может повлиять на их качество или может нуждаться в дополнительном обучении, Следовательно, изменения, приводящие к сбору информации прямо у ее источника, не будут иметь низкую стоимость с учетом множества работников.
Таким образом, для уменьшения недовольства пользователей, возможно, потребуются изменения в системе. Например, как за-
метил руководитель отдела управления информацией компании Hydro Agri: «Пользовательский интерфейс SAP был сложным для работников погрузочной площадки, которые вводят данные о количестве ввозимых и вывозимых химических препаратов» (Stedman 1998b). В результате, компании Hydro Agri пришлось создать интерфейс для улучшения практичности и доступности. Такие проблемы могут замедлить процесс внедрения и вызвать недовольство пользователей.
Сбор данных с акцентом на процессе (а не на функции)
В традиционных системах сбор данных обычно базируется на нуждах конкретных функциональных приложений. В ERP системах, базирующихся на событиях, сбор данных осуществляется с точки зрения кросс-функциональности, т. е. с акцентом на процессе. В результате, если информация собирается у источника ее порождения, то последовательность происхождения данных может изменяться вместе с процессом.
Кроме того, при использовании традиционных систем скрытая модель фирмы, вероятно, более основана на функциях, которые фокусируются на конкретных функциональных информационных нуждах. Переход к межфункциональным событиям может породить модель фирмы с более широкой основой, удовлетворяющей более широкому диапазону информационных нужд. Системы планирования ресурсов предприятий, такие как SAR моделируют фирму на уровне определенных «пусковых механизмов» — различных событий, определяющих, когда нужно собирать информацию для системы. В книге Ванга, Гилланда и Ли (Whang, Gilland, and Lee 1995, с. 8, 26) говорится о том, что среди пусковых механизмов SAP могут быть следующие:
сбытовая деятельность, начиная с контакта с клиентом;
прием грузов, начиная с заказа на поставку;
резервирование материала для запланированного использования;
проблемы с товарами (например, изъятие материала);
отправка по почте (изменение номера партии, изменение названия среди подразделений);
перевод акций (например, перемещение внутри компании с одного предприятия на другое);
перемещение товаров по наряд-заказам (детали со склада, готовые товары на склад).
В некоторых случаях некоторые акценты по сравнению с тем, как традиционная система собирает ту же самую информацию, могут
меняться: когда информация собрана, кто ее собрал и ее последовательность. Такое фокусирование на событиях ——пусковых механизмах имеет не только преимущества, но и влечет за собой затраты. Среди выгод ——возможность создания лучшей в мире модели функционирования компании. Например, функциональный подход, основанный на традиционных системах, рассматривает события, важные в первую очередь на функциональном уровне, и не затрагивает более широкие информационные нужды. Переход к межфункциональному процессу мог бы заменить систему, основанную на событиях, системой, базирующейся на лучшем моделировании фирмы. Издержки могли бы включать изменения статус-кво, что могло бы привести к недовольству пользователей.
Изменение процесса и персонала ввода данных:недовольство пользователей
Изменения, привносимые реинжинирингом, сопровождающим внедрение ERP систем, могут привести к изменениям процессов и обязанностей персонала, ответственного за ввод данных. При изменении процессов происходят сопутствующие изменения в сборе данных: того, как часто, где и кем они собираются. Если при переходе от традиционной системы к ERP системе процессы изменяются не сильно, и так же не сильно меняются обязанности людей, ответствен-
СходныеСходныеРазличныеРазличныеПерсонал, собирающий данныеПерсонал, собирающий данныеfMrad ①方 нчох° ■SOHOSO x-qHHOHtluvedl 30§0аЕ £ dH山-qooohodufMrad ①方 нчох° ■SOHOSO x-qHHOHtluvedl 30§0аЕ £ dH山-qooohoduРис. 4.1 Изменение процесса и персонала, собирающего данныеРис. 4.1 Изменение процесса и персонала, собирающего данные
Сходные
Сходные
Различные
Различные
Персонал, собирающий данные
Персонал, собирающий данные
fMrad ①方 нчох° ■SOHOSO x-qHHOHtluvedl 30§0аЕ £ dH山-qooohodu
fMrad ①方 нчох° ■SOHOSO x-qHHOHtluvedl 30§0аЕ £ dH山-qooohodu
Рис. 4.1 Изменение процесса и персонала, собирающего данные
Рис. 4.1 Изменение процесса и персонала, собирающего данные
ных за ввод данных, то при внедрении ERP системы с вводом данных не возникнет больших трудностей.
Однако если процесс и обязанности персонала, собирающего данные, меняются, то внедрение становится более проблематичным в связи, например, с недовольством пользователей. К сожалению, пока не произойдет изменений в процессах, связанных со сбором данных, не будет возможности создать выгоды, связываемые с ERP системой. Следовательно, существует противоречие между преимуществами, связанными с изменениями, и дезинтеграцией, которая может возникнуть в организации из-за принятия этих изменений (см. рис. 4.1).
Слишком много окон и слишком много временина ввод данных?
Системы планирования ресурсов предприятий ——это готовое ПО, разработанное для внедрения различными фирмами. Для обеспечения гибкости системы и охвата более широкой информационной базы окна для ввода данных ERP системы основаны на предоставлении наиболее общих возможностей проектирования. Не удивительно, что многим фирмам не нужны все возможности сбора данных, которые предоставляются этими большими ERP системами. Однако конфигурирование не может уменьшить число окон, которые должны быть заполнены. Например, версии системы SAP R/3, предшествовавшие версии 4.03 были менее гибкими в перенесении полей данных в единое окно. В результате, ввод данных в ERP системе может потребовать большего количества окон, чем если бы последовательность окон была бы специально разработана для конкретных нужд ввода данных. Большее число окон означает большее количество данных, больше времени и, следовательно, больше персонала для ввода данных. Системам, специально разработанным для нужд конкретной компании, может, таким образом, потребоваться меньшее время на ввод данных и меньше ресурсов, чем ERP системе.
Hydro Agri
В канадских магазинах фирмы Hydro Agri обработка заказа фермера занимала раньше 20 секунд. Однако после установки системы SAP R/3 время обработки возросло примерно до 90 секунд (Stedman 1998b). Так как Hydro Agri имеет около 30 000 заказов каждые четыре недели, новой системе для ввода данных требовались огромные ресурсы. До установки R/3 для обработки заказов каждые четыре неде-
ли требовалось 600 000 секунд, после установки — 2 700 000 секунд. В результате, заказы пришлось принимать штату сотрудников подразделения информационных технологий.
Используя R/3, работникам пришлось вводить данные в шесть окон. В предыдущей же (собственного производства) системе для ввода данных было только одно окно. Кроме того, рабочие процессы в системе R/3 значительно отличались, так что даже работники, ответственные за ввод данных, были другими по сравнению с системой собственного производства. Следовательно, переход к новой системе привел к появлению необходимости дополнительного обучения персонала.
По словам руководителя управления информацией фирмы Hydro Agri, увеличившиеся требования к вводу заказов «грозили стать концом всего». Таким образом, фирма Hydro Agri была вынуждена выбирать между установкой какого-то нового пакета для ввода заказов или разработкой своего собственного пакета, сделанного на заказ. В конечном итоге Hydro Agri решила эту проблему, создав приложение между R/3 и пользователями для упрощения и объединения доступа.
Почему увеличилось количество окон
для ввода информации и время обработки данных?
Перенесение внимания с функции на процесс привело к изменению последовательности сбора информации, а также того, кто должен собирать информацию, и, как результат, — к различному числу окон для ввода данных. Например, в фирме Hydro Agri в системе R/3 было шесть окон, в то время как у традиционной системы — всего одно. ERP система была создана, исходя из процесса, с учетом множества источников информации — отсюда необходимость нескольких окон. Однако традиционная система была создана для удовлетворения конкретной функциональной потребности. В результате в данном случае, возможно, не было хорошего соответствия ПО существующему организационному процессу. Позже в данной книге мы более подробно рассмотрим отношения между организационными процессами и ПО.
Количество окон для ввода данных и деловых операций: модель трудностей внедрения
Если количество окон в новой ERP системе значительно больше, чем в традиционной системе, это может привести к увеличению времени, требующегося для ввода данных в определенной бизнес-опе- рации.
Это может привести к потере заказов или к увеличению ресурсов, необходимых для поддержки процесса ввода данных. Если операций
НебольшоеБольшоеКОЛИЧЕСТВО ОПЕРАЦИЙ ПО ВВОДУ ДАННЫХРис. 4.2 Число окон для ввода данных и операцийНебольшоеБольшоеКОЛИЧЕСТВО ОПЕРАЦИЙ ПО ВВОДУ ДАННЫХРис. 4.2 Число окон для ввода данных и операцийQomquom ① omquogoH rasoROSO sxxo#ss& / BIAls&no-dH山 ^X_XXX3 ssa K5 Ho*。ramRoo^sl ф^хфзохноооQomquom ① omquogoH rasoROSO sxxo#ss& / BIAls&no-dH山 ^X_XXX3 ssa K5 Ho*。ramRoo^sl ф^хфзохнооо
НебольшоеБольшое
КОЛИЧЕСТВО ОПЕРАЦИЙ ПО ВВОДУ ДАННЫХ
Рис. 4.2 Число окон для ввода данных и операций
НебольшоеБольшое
КОЛИЧЕСТВО ОПЕРАЦИЙ ПО ВВОДУ ДАННЫХ
Рис. 4.2 Число окон для ввода данных и операций
Qomquom ① omquogoH rasoROSO sxxo#ss& / BIAls&no-dH山 ^X_XXX3 ssa K5 Ho*。ramRoo^sl ф^хфзохнооо
Qomquom ① omquogoH rasoROSO sxxo#ss& / BIAls&no-dH山 ^X_XXX3 ssa K5 Ho*。ramRoo^sl ф^хфзохнооо
немного, любое увеличение ресурсов, происходящее из-за увеличения работы по вводу данных, в общем, не будет иметь серьезных последствий* Однако если количество операций велико, то значительное увеличение числа окон (по сравнению с традиционной системой) приведет к значительному увеличению ресурсов, необходимых для ввода данных. В результате, если разница большая (например, в компании Hydro Agri соотношение было 6:1), и существует большое количество операций (30 000 в компании Hydro Agri), то систему будет труднее внедрить, если не уменьшить число окон (как это было сделано в Hydro Agri). Такое усложнение внедрения изображено на рис. 4.2.
Соотношение числа окон для ввода данных в ERP системах и числа окон для ввода данных в традиционной системе также может быть мерой оценки соответствия ERP системы существующим организационным процессам. Большой разрыв показывает, что организационные процессы и процессы ПО в значительной степени отличаются, и возможно индицирует несоответствие ПО существующим процессам.
Проектирование ERP систем
Отличия ввода данных в ERP системах от традиционных систем связаны с «конструкцией» ERP систем, в частности с вопросами, касающимися пользовательского интерфейса, БД и отношений между процессами и вводом данных.
Недостаточное внимание пользовательскому интерфейсу
Некоторые специалисты утверждают, что разработчики ERP систем не уделили достаточного внимания пользовательскому интерфейсу. Как сказал президент Human Factors International:
Разработчики данных [ERP] пакетов все без исключения исходят из подхода с точки зрения системы, а не с точки зрения пользователя ... [Из-за системы производительность пользователей снижается, так как она заставляет их «метаться между окнами» ——работать то с клавиатурой, то с мышью.] ... Это программное обеспечение просто выводит людей из себя. (Stedman 1998b).
Другие специалисты, например, аналитик из AMR Research, утверждают, что проблемы с вводом данных в ERP системах возникают из-за того, что их разработчики в основном «проектировали, исходя из базы данных, а не из пользовательского интерфейса. Окна были последним, о чем они думали».
Процессы и ввод данных
В некоторых случаях снижение производительности при вводе данных не так важно, как наличие информации для принятия решений и изменения других процессов. Как заметил директор по коммуникациям компании Procter & Gamble: «Более высокая производительность при вводе данных и получении сырья — не главная цель Реальные преимущества получают те, кто планирует бизнес, менеджеры по материалам и другие пользователи низших звеньев. Ввод данных требует в настоящее время больших усилий» (Stedman 1998b).
Ввод данных, как критерий простоты использования
Несмотря на требования ERP систем, приводящих к изменениям ввода данных и связанных процессов, «простота использования» — это фактор, который почти всегда является одним из критериев оценки при выборе ERP системы. Некоторые ERP системы проще в использовании, чем другие. Разработчики стараются сделать свои ERP системы более простыми в использовании, и у них на то много причин.
* Имеется в виду представление информации на экране компьютера (прим, науч, редактора).
Некоторые ERP системы проще в использовании,чем другие
Некоторые системы могут быть проще в использовании, чем другие, но простота использования — это не единственная переменная, которая влияет на выбор системы. Например, компания SunAmerica в конечном итоге выбрала SAP, хотя, как сказал вице-президент расчетного отдела на ежегодном собрании компании SunAmerica: «Система PeopleSoft очень привлекательна, когда смотришь на окна, в то время как [R/3] была внешне непривлекательной» (Stedman 1998а).
Однако другие пользователи обнаружили, что система PeopleSoft не проста в использовании. Как заметил Стедман (Stedman 1998b, с. 24), компания Algoma Steel начала использовать пакет управления персоналом системы PeopleSoft, но работники для получения информации все еще обращаются к мейнфрейму. Одна из причин в том, что «работникам приходится бороться с многочисленными окнами системы PeopleSoft, в то время как старая система имеет только два или три окна».
Некоторые пользователи утверждают, что конкретными ERP системами нужно уметь пользоваться. Например, главный управляющий по информации (Cief Information Officier, СЮ) компании А-dec (производящей стоматологическое оборудование) обнаружил, что после того, как компания A-dec установила ERP систему компании BAAN (Stedman 1998b, с. 24),
число звонков в справочную компании увеличилось на 65% (СЮ сказал: «Это прямо говорит о том, что нужно уметь пользоваться этим приложением»);
система не уменьшала запасы на то количество, которое было отправлено. Хотя работники складов ввели необходимые данные о вывозе запасов, им пришлось в другом окне подтверждать операцию, прежде чем система производила вычет из запасов. К сожалению, система не потребовала подтверждения.
Разработчики пытаются сделать системыболее простыми для использования
Простота использования — достаточно важный фактор. Как сказал Басс (Bussei998), SAP пытается сделать систему доступной для большего числа пользователей. Как заметил Хассо Плеттнер, главный администратор (Chief Executive Officer, СЕО) и один из основателей компании SAP: «Я хочу, чтобы люди могли использовать часть [системы R/3] без дополнительного обучения». В результате, компания SAP начала то, что она называет «EnjoySAP», в качестве попытки сделать
R/3 проще в использовании и легко приспосабливаемой к более широкому кругу условий работы. Эти попытки задействуют различные технологии, включая сенсорные экраны для упрощения ввода данных.
Однако Стедман (Stedman 1998а), цитируя Плеттнера, говорит: «В результате не такое количество пользователей используют SAP, какое мы ожидали». Этот вопрос важен для производителей ERP систем по нескольким причинам. Во-первых, если система недостаточно проста в использовании, ее могут не продать стольким фирмам, скольким могли бы, будь она проще. Во-вторых, если простота использования не будет иметь значения при внедрении системы конкретными фирмами, она все равно может повлиять на доходы, потому что доходы часто зависят от количества проданных «рабочих мест» (т.е. от числа пользователей системы). В результате, некоторые фирмы предоставили менее заинтересованным пользователям доступ к финансовой и другой информации через intranet, оставляя прямой доступ к сети только экспертам (Bashein, Markus и Finley 1997).
Важно отметить, что «простота использования» в некоторой степени «находится в глазу наблюдателя». Если система кажется нам знакомой, нам, возможно, проще ее использовать. Например, Браунли (Brownlee 1996) говорит, что один пользователь заметил: «Я не знал, как работает старая система... Я думаю, что, возможно, в этом мое преимущество».
Резюме
Реинжиниринг; осуществляемый при внедрении ERP систем, в конечном итоге приводит к изменениям того, сколько раз, как, ще и когда собираются данные. Хотя каждое из изменений может принести определенные выгоды, изменения могут также привести и к недовольству пользователей. В конечном итоге нужно взвесить преимущества от изменений и недовольство пользователей, и могут понадобиться дополнительные усилия для уменьшения недовольства пользователей.
Традиционные системы могут обеспечить фактически более эффективный сбор определенных наборов данных. Например, для информации, которую можно собрать в традиционной системе в одном окне, в ERP системе понадобится от трех до шести окон. Это обеспечило базис для модели трудностей внедрения, сравнивающей традиционные и ERP системы (а) по количеству необходимых окон и (б) в свете числа операций ввода. По мере того, как эти факторы возрастают, сложность внедрения растет.
Хотя все производители ERP систем признают важность потенциала ввода данных, некоторые системы окажутся, возможно, более простыми в использовании, чем другие. В любом случае, разработчики ERP систем делают попытки (например, «EnjoySAP») сделать системы более простыми в пользовании.
Литература
BasheinI В., Markus, L, and Finley, J. (1997). Safety Nets: Secrets of Effective Information Technology Controls. Morristown, NJ: Financial Executives Research Foundation.
Brownlee, L (1996). «Overhaul». Wall Street Journal, November 18, pp. R12, R17. Busse, T. (1998). «SAP to Broaden Access to R/З». Computerworld, September 15.
Hammer, M. (1990). «Reengineering Work: Don't Automate, Obliterate». Harvard
Business Review, July/August, pp. 104-12.
Koch, C. (1999). «The Most Important learn in History». CIO Magazine, October 15. Stedman, C. (1998a). «R/З Complexity Stymies Users». Computerworld , September 21.
Stedman, C. (1998b). «ERP User Interfaces Drive Workers Nuts». Computerworld, November 2, pp. 1, 24.
Whang, S., Gilland, W., and Lee, H. (1995). «Information Flows in Manufacturing under SAP R/3»* OIT no. 13, Graduate School of Business, Stanford University, Stanford, CA.
ВОЗМОЖНОСТИ ВЫВОДА ДАННЫХ В ERP СИСТЕМАХ
Доступ к информации в ERP системах сначала ограничивался отчетами, которые можно было получить из системы или через запросы к БД, лежащей в основе модели БД, Однако в последнее время организации стали использовать для дальнейшего распределения информации, созданной ERP системой, intranet и хранилища данных. Кроме того, чтобы предоставить пользователям индивидуальный доступ к различной информации, производители ERP систем начали разрабатывать «порталы». Это привело к упрощению использования и, следовательно, к появлению новых возможностей для производителей ERP систем в электронной коммерции.
Возможности создания отчетов и запросов в ERP системе
При использовании ERP систем информация доступна для конкретных пользователей в форме конкретных отчетов. Кроме того, существуют другие методы вывода данных, в том числе запросы в БД. В последнее время возможности создания отчетов в ERP системах стали развиваться, так как их производители попытались увеличить доступность и упростить использование этих систем.
Отчеты ERP систем
Системы планирования ресурсов предприятия могут создавать различные стандартные отчеты, которые спроектированы для стандартного принятия решений. Отчеты, предоставляемые системой, зависят от конкретного модуля. Например, финансовые модули создают классические финансовые отчеты, включая декларации о доходах и бухгалтерские балансы.
Однако отчеты ERP системы не всегда соответствуют нуждам пользователей, как видно из нескольких примеров, которые мы приведем в данной главе. Следовательно, фирмам, возможно, нужно будет найти альтернативные методы создания таких отчетов. Заметьте, что возможности создания отчетов ERP систем не всеми пользователями используются легко, и, кроме того, существует такое понятие, как цена «рабочего места» — стоимость ERP системы обычно зависит от числа пользователей системой. В результате, некоторые фирмы создают отчеты и вводят их в другие среды (например, в intranet), так что экспертиза с помощью ERP не всеща требует использовать возможности этих систем по созданию отчетов.
Запросы в базу данных
Системы планирования ресурсов предприятий обычно имеют под собой реляционные БД. В результате, используя или БД, или возможности запросов ERP систем, можно создавать отчеты, базирующиеся на основной информации, и делать их доступными. Запросы особенно необходимы в том случае, если отчеты, созданные ERP системой, не соответствуют нуждам пользователя.
Запросы в БД могут выполняться на одном из двух уровней. Во- первых, в ПО ERP систем обычно заложена возможность формирования запросов. Во-вторых, внутри БД (например, Oracle), включенной в ПО ERR также есть возможность формирования запросов. Обычно организации используют возможности одного из этих двух уровней.
Системы планирования ресурсов предприятий были спроектированы для обработки операций. Поэтому, не удивительно, что в некоторых ERP системах запросы рассматриваются как операции. Однако, чем больше сделано запросов, тем больше опасность перегрузки системы; слишком большое число запросов может увеличить время ответа и неблагоприятно отразиться на пользователях. Например, как заметил Коч (Koch 1999):
Отчеты являются большой проблемой ERP систем, потому что впервые сотни, даже тысячи служащих обращаются к единственной интегрированной базе данных ERP системы и выводят огромное количество данных ... Это проблема технологии номер один, которую команды по внедрению ERP системы должны устранить после внедрения системы.
Таким образом, важной частью планирования производительно- сти ERP системы является определение того, как будет определен и осуществлен вывод данных. Если он осуществляется через запросы, то потребуются дополнительные оборудование и пропускная способность сети.
Что если возможности создания отчетов недостаточны?
Если возможности создания отчетов и запросов ERP системы не удовлетворяют нужды фирмы, существует три выхода из этой ситуации. Во-первых, фирма может создать отчеты на заказ. Во-вторых, она может ввести отчетную информацию в intranet. В-третьих, может быть разработано хранилище данных для удаленных и специальных запросов.
Отчеты, созданные на заказ
Преимущество отчетов, созданных на заказ, заключается в предоставлении возможности конкретным лицам, принимающим решения (ЛПР), извлечь нужную информацию в виде отчета, выпускаемого периодически. Однако наряду с явным достоинством здесь есть и недостатки. Во-первых, нужды ЛПР со временем меняются в соответствии с изменениями среды и их пониманием решаемых ими проблем. Во-вторых, ЛПР меняются на организационных должностях: пользователей повышают по службе, принимают на работу или увольняют. В случае если отчет спроектирован под конкретного поль-
зователя, при изменении пользователя отчет также необходимо будет изменить. В-третьих, специально спроектированные отчеты могут содержать информацию, не нужную ЛПР, или могут не содержать всей нужной информации. В-четвертых, создание заказной ERP системы может оказаться слишком дорогим удовольствием и уменьшить возможности модернизации системы. В общем, создание специальных отчетов на заказ в системе может быть дорогим и кратковременным решением.
Intranet
Так как ERP системы, в общем, не просты в пользовании, некоторые фирмы помещают отчеты в Интернет или в intranet. В частности, для различных уровней пользователей могут быть созданы различные среды создания отчетов. Например, пользователям-экспертам можно предоставить прямой доступ к SAP, в то время как остальным — доступ к той информации, которая им нужна, в удобном для использования формате в корпоративной сети intranet.
Интеграция intranet и ERP системы все в большей степени становится средством распространения отчетной информации в ERP системах. Например, компания Transamerica в Лос-Анджелесе использует intranet для того, чтобы сделать доступной отчетную информацию из системы PeopleSoft. Отчеты, разработанные для того, чтобы удовлетворить и общий, и конкретный интерес при принятии решений, обновляются каждые 24 часа.
Более того, для доступа к данным ERP системы, чтобы генерировать более удобные для чтения и использования отчеты, может быть использован и Lotus Notes. Например, Lotus Notes дает доступ к данным систем PeopleSoft и SAP (Doan 1996). Такой доступ позволяет организациям делать данные ERP систем доступными в системе, знакомой пользователям, к которой легко получить доступ и которую просто использовать.
Отчеты, опубликованные в intranet, обычно являются стандартными отчетами, распространяемыми для общего доступа. В результате, сама информация в целом почти та же самая, что и находится в отчетах ERP системы. Что меняется, так это доступность: информация становится доступной для более широкого круга пользователей.
Хранилища данных
В некоторых случаях ERP системы имеют интерфейс к хранилищам данных. Хранилища данных могут предоставить, по крайней мере, две возможности. Во-первых, они дают пользователю возможность получить доступ к информации, необходимой для принятия решений, в среде, созданной для генерирования отчетов. Во-вторых, хранилище данных может функционировать как класс «клиринговых домов» по отношению к приложениям, обеспечивающим исходящие и входящие потоки данных как для внутренних, так и для внешних пользователей. Например (Cotteleer, Austin, and Nolan 1998, с. 10), компания Cisco использовала хранилище данных при внедрении Oracle Applications:
Так как последствия внедрения [Oracle Applications] для исходящих потоков были большими, чем ожидалось, команда внедрения решила обратиться к некоторым другим техническим источникам. Поскольку до этого системы были связаны друг с другом напрямую (т. е. по принципу «точка-точка»), при новом подходе все данные будут передаваться через «хранилище данных».
Хранилища данных могут быть физически расположены в одном месте или же представлять из себя «виртуальные» хранилища, части БД которых расположены в нескольких местах. В приложении 5-1 говорится о том, как ERP система компании Quantum взаимодействует с виртуальным хранилищем данных. Далее говорится о том, как компания Burton Snowboards использовала единое хранилище данных.
Хранилище данных компании Burton Snowboards
(Kempster 1998)
Компания Burton Snowboards использует систему SAP R/3 как систему обработки операций для фиксации данных, поступающих из трех ее офисов, расположенных в Австрии, Японии и Вермонте. Компания обнаружила, что создавать нестандартные отчеты в системе SAP было слишком сложной задачей. Небольшая группа информационных систем не могла размещать запросы из-за сложности SAR
Кроме того, компания обнаружила, что, используя возможности создания отчетов системы SAP, было сложно выполнить даже некоторые простые задания. Например, директор подразделения информационных систем компании Burton Snowboards сказал:
Нам нужно было что-то, что дало бы менеджеру службы материально-технического снабжения или менеджеру по продукции возможность следить за материально-техническим снабжением, не запрашивая информацию в отделе информационных систем... Эта информация нужна широкому кругу лиц, таким как члены наших команд продаж, материально-технического снабжения, управления и нашей группы информационных систем.
Чтобы удовлетворить стандартные и нестандартные запросы, компания Burton внедрила хранилище данных. Она ежедневно переносит информацию из системы SAP в хранилище данных и затем использует инструмент управления отчетами (Vista/EA) для просмотра данных. Около 70% менеджеров среднего звена компании Burton и почти все исполнители пользуются выходными данными системы.
Обнаружение знаний
Хранилище данных может быть использовано не только для предоставления отчетов. Так как данные находятся в одном месте, фирмы могут создавать или находить знания в данных. Например, могут быть исследованы отношения между различными переменными с использованием статистического подхода и методов искусственного интеллекта. Такие знания позволяют создавать ценности из действий по обработке деловых операций. Ранее же расходы на системы обработки операций рассматривались как чисто накладные.
Преимущества хранилищ данных
Производители ERP систем все чаще интегрируют возможности хранилищ данных в свои системы. Из-за своей специализации на БД компания Oracle была, возможно, первым основным производителем, кто интегрировал хран ил и ща дан н ых в свой продукт. Однако SAP также вскоре выпустила продукт с хранилищем данных.
Хранилища данных предлагают информацию, оптимизированную для поиска. Таким образом, так как процессы принятия решений нуждаются в изменениях, хранилище данных может быть использовано для предоставления новых отчетов в режиме реального времени. Как видно из примера компании Cisco, хранилища данных могут
быть также использованы, как центральные пункты взаимодействия. Расходы в основном идут на создание и содержание хранилищ данных, а также на написание запросов к ним.
Порталы ERP систем
Так как фирмы все больше используют intranet и хранилища данных, производители ERP систем стали предоставлять порталы, способствующие развитию доступа для пользователей ERP систем. Некоторые из порталов производителей ERP систем представлены в таблице 5.1,
Таблица 5.1 Порталы производителей ERP систем
Производитель
Портал
J.D. Edwards
MyActivEra
Lawson
Insight II Seaport
PeopleSoft
MyWorld
SAP
MySAP
Среди производителей ERP систем понятие «портал» устоялось пока не полностью. Как сказал аналитик МЕТА group: «Эти производители собирают все, что подойдет, и смотрят, что приживется» (Holt and Lamonica 1999). В основном, портал ERP системы — это web-сайт (в intranet или в Интернете), который предоставляет доступ к новостям и информации, опосредованно или прямо связанной с ERP системой. Порталы ERP систем обеспечивают поддержку продаж продуктов, связанных с ERP, в среде электронной коммерции. Порталы некоторых производителей ERP систем (например, MySAP.com компании SAP) позволяют предлагать свои товары или услуги другим производителям продуктов, связанных с системой SAR
Используются две версии: для настольного компьютера и базирующаяся на web-сервере. Компания Lawson выпустила недавно образцовую модель для настольного компьютера (см. рис. 5.1), разработанную для конкретного работника или профессиональной деятельности. В рамках модели пользователь получает доступ к различ-
* World-Wide Web — «всемирная паутина». Одно из названий Интернета. Часто так называют и серверы, на которых хранятся документы, связанные между собой гиперссылками (прим. науч, редактора).
ERP СИСТЕМЫ
Рис. 5.1
ным необходимым ему подмодулям ERP системы (например, заявкам, заказам на поставку), к справочной функции и различным отчетам. Возможности электронной коммерции предоставляются на этой же странице в виде доступа к каталогам поставщиков, страницам компании Lawson и информации о поставщиках информационного наполнения (контента). Кроме того, страница предоставляет место для помещения в центре личной информации, например, календаря, основных контактов, электронной почты и т. д. И, наконец, на рабо-
я容醃‘撼像陶瑟^ *4強-я容醃‘撼像陶瑟^ *4強-вв義.绯健購務《1館啜触》猫fgfc義.绯健購務《1館啜触》猫fgfcзй icsfcs feam Siis xhwenet hm bw$c saieetes iзй icsfcs feam Siis xhwenet hm bw$c saieetes i
я
容醃‘撼像陶瑟^ *4強-
я
容醃‘撼像陶瑟^ *4強-
в
в
義.绯健購務《1館啜触》猫fgfc
義.绯健購務《1館啜触》猫fgfc
зй icsfcs feam Siis xhwenet hm bw$c saieetes i
зй icsfcs feam Siis xhwenet hm bw$c saieetes i
Рис. 5.2
чем столе есть место для размещения ежедневных новостей, которое может быть использовано компанией для донесения необходимой информации до ее служащих.
MySAP — это портал, основанный на web-сервере (см. рис. 5.2 и 5.3) с возможностями персонализации. Пользователи выбирают нужные им разделы (topics) (бизнес-справочник, бизнес-процессы, тенденции в отрасли и т. д.) и направления (channels) (например, такие отраслевые аспекты, как высокие технологии).
Использование intranet и хранилищ данных означали потерю контроля над некоторой информацией ERP систем, а использование настольных версий портала и персонализированных станиц web-сервера возвращают контроль производителям ERP систем. В то время, как перевод информации в общую корпоративную сеть вывел ее за пределы ERP системы, порталы могут централизовать информацию в среде продуктов производителя и сделать ее еще более общедоступной.
Резюме
Создавать отчеты в ERP системе можно, используя несколько способов, в том числе используя запросы к БД и возможности ERP систем в создании отчетов. Однако некоторые фирмы сделали информацию доступной для менее заинтересованных пользователей через корпоративные сети (intranet). Кроме того, важным средством создания отчетов или сбора представлений являются хранилища данных.
Одно из дополнительных преимуществ их использования — возможность извлечения знаний из данных, созданных в ERP системах.
За последнее время представление выходных данных ERP систем стало осуществляться не в виде отчетов, а в виде спроектированного в соответствии с нуждами клиента рабочего стола, использующего информацию с портала. Кроме доступа к отчетам, специально разработанная модель обеспечивает доступ к соответствующим частям ERP системы и ее отчетам, новостям и личной информации, такой как календарь или электронная почта.
Литература
Cotteleer; М., Austin, R., and Nolan, R. (1998). «Cisco Systems, Inc.: Implementing ERP». Report no. 9-699-022, Harvard Business School, Cambridge, MA.
Doan, A. (1996). «Domino Gets Back-End Links». Infoworld, December 2.
Holt, S., and Lamonica, M. (1999). «ERP Vendors Join the Ranks of Web Portal
Sites». lnfoWorldI May, 31.
Kempster, L. (1998). «ERR Warehouse Used in Concert». Computerworld, September 21.
Koch, C. (1999). «The Most Important Team in History». CIO Magazine, October 15.
Приложение 51*
Виртуальное хранилище данных компании Quantum
Quantum
Корпорация Quantum была основана в 1980 匚 Производитель различных запоминающих устройств большой емкости компания Quantum выпускает накопители на жестких дисках для персональных компьютеров и все виды ленточных накопителей.
Quantum — лидер рынка производства и стационарных, и переносных запоминающих устройств. Quantum продает свою продукцию изготовителям комплектного оборудования и дилерам во всем мире. Компания имеет девять предприятий, расположенных на территории Северной Америки, Европы и стран тихоокеанского бассейна. В период с 1996 по 1998 гг. объем продаж компании за финансовый год, завершающийся в марте, возрос с 4,4 до 5,8 млрд, долларов.
Внедрение ERP системы компании Oracle
В 1996 г. Quantum внедрила Oracle Applications в финансовой сфере и производстве, базирующуюся на СУБД компании Oracle. В полученной в результате системе использовалось более 40 000 основных таблиц. К сожалению, из-за этого огромного количества таблиц информацию для принятия решений использовать было сложно. Среда серверной СУБД по обработке деловых операций была слишком сложной для многих пользователей и, казалось, система обречена на то, чтобы стать хранилищем мало использующейся информации об этих операциях. Компания Quantum должна была предпринять действия, направленные на облегчение доступа к информации.
Виртуальное хранилище данных
Чтобы сделать информацию о деловых операциях доступной для менеджеров и других служащих, принимающих решения, компания Quantum выбрала хранилище данных. Для упрощения доступа к данным были созданы около 4 тыс. упрощенных и бизнес-ориентирован- ных представлений БД. Кевин Конвей, менеджер по программам подразделения информационных систем, рассказал:
Цель нашего подразделения — обеспечить конечным пользователям доступ к корпоративным данным для ведения бизнеса.
Нам нужно было сделать доступными для конечных пользователей все данные о деловых операциях в качестве рабочей бизнес-ин- формации в системе планирования ресурсов предприятия фирмы Oracle и сделать его всеобъемлющим, имея большое число различных бизнес-единиц.
Виртуальное информационное хранилище компании Quantum позволяет «заглянуть в будущее» всех операций компании:
Подразделение информационных услуг компании Quantum создало так называемое «виртуальное хранилище данных». Эта уникальная стратегия, совмещающая несколько различных технологий, позволяет девяти предприятиям корпорации соответствовать важным требованиям создания отчетов, предоставляя по требованию отчеты обо всех операциях компании. Эта стратегия использования множества серверов обеспечивает сохранение непрерывной обработки деловых операций в режиме реального времени, а также быстрое создание отчетов: ни одна из бизнес-функций не мешает дру- пэ访，и работа может быть выполнена за более короткое время.
Использование хранилища данных
В настоящее время хранилище данных обслуживает в среднем 250 пользователей (в любую смену) 23 часа в сутки, шесть дней в неделю. Им пользуются служащие предприятий корпорации, расположенных по всему миру. Система была спроектирована для удовлетворения потребностей в информации служащих, занятых в различных видах деятельности компании Quantum, включая перевозки, финансы, продажи и управление, а также операционных и временных менеджеров.
Диана Шен, менеджер по управлению стратегическим процессом, заметила:
Эта система предоставляет нам доступ в режиме реального времени к данным в виде консолидированных отчетов, что упрощает работу с данными. Доступ в режиме реального времени позволяет нам принимать более эффективные бизнес-решения. Мы можем отследить, где транспортируется продукция, если поставщики обеспечивают своевременную доставку, и информацию о различиях в ценах производителей, и все это мы можем немедленно передать нашим покупателям или менеджерам. Это помогает нам снизить затраты и эффективнее обслуживать наших клиентов и партнеров.
Хранилище данных позволило интегрировать и «подстроить» некоторые отчеты для более быстрого удовлетворения нужд ЛПР Например, на то, что сейчас предоставляется в одном отчете, ранее требовалось 15 отчетов и 16 часов на их создание.
Фирмы, задействованные при внедрении
Развитие хранилища данных потребовало объединения в одной команде различных фирм, и кроме фирмы Oracle, были задействованы фирмы Hewlett-Packard, Brio Technology, Noetix Corporation и Integral Results.
Хранилище данных было внедрено в среде клиент-сервер при использовании серверов HP 9000 Enterprise Servers фирмы Hewlett-Packard.
Корпорация Noetix разработала продукт Noetix Views, который обеспечивает полный набор представлений, разработанный для модулей Oracle Applications, включающих Главную книгу, «Дебиторскую задолженность», «Кредиторскую задолженность», «Управление запасами», «Заказы на поставку» и «Входящие заказы».
Компания Brio Technology обеспечила аналитическую обработку в реальном времени (on-line analytic processing, OLAP) и возможности создания отчетов пользователям в средах клиент- сервер и Интернет. Для доступа к данным из Oracle Applications компания Quantum использует Brio Enterprise в сочетании с Noetix Views. Кроме того, команда компании Oracle по внедрению хранилища данных использует BrioQuery для создания новых запросов.
Integral Results ——это консалтинговая фирма, специализирующаяся на хранилищах данных и системах поддержки принятия решений. Она обучила пользователей запрашивать и просматривать данные, используя BrioQuery. Integral Results с 1993 二 сотрудничает с Brio Technology по нескольким проектам. Брок Элстон (региональный менеджер компании Brio Technology) рекомендовал фирме Integral Results помочь компании Quantum в обучении использованию продуктов компании Brio Technology. Как заметил Кевин Конвей: «Чтобы достичь успеха, мы использовали наших клиентов и номера моделей жестких дисков в качестве примеров для обучения».
Роль компании Quantum во внедрении
Для внедрения системы компания Quantum использовала сочетание (50/50) информационных услуг и ресурсов бизнес-пользователей.
Внедрение оказалось успешным благодаря слаженной работе на- ше访 команды... Системные бизнес-аналитики каждого предприятия корпорации выясняли требования пользователя к операционной информации, построению запросов и обучению. Программисты региональных подразделений информационных систем и аналитики при необходимости предоставляли техническую помощь. Благодаря этой командной работе предприятия корпорации учились друг у друга, и внедрение шло быстрее при высокой степени одобрения пользователей.
Обеспечение хранилищ данных кадрами
Хранилищу данных требуется команда для поддержания текущих потребностей пользователей, системных изменений и обучения. Кроме менеджера программы, персонал хранилища данных включает двух консультантов (старших аналитиков-программистов), двух бизнес-аналитиков информационных услуг; одного технического инструктора и инженера поддержки. Как заметил Лорен Гранер: «Кевин Конвей ... создал целую команду, которая поддерживает глобальную инфраструктуру компании Quantum».
Выявленные проблемы
При внедрении хранилища данных компания Quantum столкнулась с несколькими проблемами: обучение в глобальных масштабах; развитие экспертизы доступа к данным; использование различного оборудования, ПО и консалтинговых фирм; поддержание работы проекта.
Обучение в глобальных масштабах. Так как хранилище данных внедрялось во всемирных масштабах, то и обучение придется проводить в этих масштабах. В результате возникнут языковые сложности и другие проблемы.
Совершенствование экспертизы доступа 咒 данным. С развитием хранилища данных компании Quantum стало необходимо совершенствовать доступ к данным и создание отчетов для того, чтобы соответствовать специальным и текущим требованиям к созданию отчетов. Для этого необходимо обеспечение кадрами, обучение и инструментальные средства.
Различное оборудование, ПО и консалтинговые фирмы. Объединять работу нескольких фирм всегда сложно. Однако Лорен Гранер (президент компании Integral Results) полагает, что у каж-
дой из задействованных команд по реализации проекта была одна общая цель:
Я думаю, что обе компании [Brio и Integral Results] имеют единую точку зрения на работу с клиентами. Работа с клиентами означает понимание того, что нужно для получения хорошего продукта — неважно, доставляете вы продукт или внедряете его на предприятии клиента.
Вопросы
Почему компания Quantum использовала хранилище данных, если у нее уже была система планирования ресурсов предприятия?
Почему компания Quantum использовала сочетание (50/50) информационных услуг и ресурсов бизнес-пользователей?
Что такое виртуальное хранилище данных? Как вы думаете, чем оно отличается от обычного хранилища данных?
Какие расходы требуются на развитие и управление хранилищем данных? Насколько эффективны изменения с учетом затрат и результатов?
Какую разновидность партнерства мы видим при внедрении хранилищ данных?
6
РЕИНЖИНИРИНГ, «ЗАПУСКАЕМЫЙ ТЕХНОЛОГИЕЙ», ПРОТИВ РЕИНЖИНИРИНГА «С ЧИСТОГО ЛИСТА»
Системы планирования ресурсов предприятий являются основным средством сбора и внедрения лучших практик. Как заметил Хеммер (Hammer 1997): «SAP — это вынужденный реинжиниринг». Вице- президент компании Cap Gemini сказал следующее по поводу внедрения ERP систем: «Редко, когда не требуется делать реинжиниринг» (Gendron 1996). Х^кендрон называет ERP «электронным воплощением реинжиниринга». Так как реинжиниринг столь тесно связан с внедрением ERP систем, фирмы должны обратиться к проблеме выбора между реинжинирингом «с чистого листа» и реинжинирингом, «запускаемым технологией».
Цель данной главы ——исследование отношения между этими двумя видами реинжиниринга. В частности, здесь описываются некоторые достоинства и недостатки каждого из этих подходов с точки зрения причин выбора фирмами одного из них. Кроме того, в данной главе исследуются некоторые характеристики фирмы, которые влияют на выбор того или иного способа реинжиниринга.
Средства и технологии реинжиниринга
Идеи Хеммера (Hammer 1990) относительно реинжиниринга появились прежде, чем инструменты для его осуществления. Многие предшествующие попытки реинжиниринга сводились к отказу от существующих процессов, но инструментов осуществления реинжиниринга было мало. Таким образом, одной из основных причин провала попыток реинжиниринга было отсутствие достаточного количества инструментов для его осуществления. Основное внимание при предшествующем анализе (CSC Index 1994) инструментов, которые использовались при реинжиниринге1 уделялось анализу ценности процесса, сравнительному тестированию (benchmarking), конкурентному анализу и функционально-стоимостному анализу. В таблице 6.1 приведены итоговые данные исследования CSC Index (1994), проведенного с целью понять, какие «технологии» были использованы для помощи в выборе процесса или объектов, нуждающихся в реинжиниринге.
Таблица 6Л. Средства, использованные для выбора того, что нужно подвергать реинжинирингу
Средство
США
Европа
Нет
41%
36%
Анализ ценности процесса
36
27
Сравнительное тестирование
34
36
Конкурентный анализ
25
28
Функционально-стоимостной анализ
20
17
Другое
16
17
Источник: CSC Index (1994).
Так как это исследование вышло до того, как ERP системы получили широкое распространение, они, естественно, не рассматривались как инструмент такого выбора. Возможно, ближайшим к ним инструментом является «сравнительное тестирование», в рамках которого могут быть собраны лучшие практики других фирм. Кроме того, со време-
ни проведения данного исследования появились другие инструменты, разработанные для реинжиниринга, некоторые из которых были включены в ERP системы. В настоящее же время ERP является доминирующей технологией реинжиниринга. Но с появлением новых инструментов вопросы выбора между реинжинирингом, «запускаемым технологией», и реинжинирингом «с чистого листа» становятся актуальными.
Что такое реинжиниринг, «запускаемый технологией»,и реинжиниринг «с чистого листа»?
Фактически, реинжиниринг осуществляется с использованием целого спектра подходов: от подхода с «запускающей технологией» до реинжиниринга «с чистого листа».
Реинжиниринг,《запускаемой (вынуждаемый)технологией»
При реинжиниринге, «запускаемом технологией», прежде чем системы, объекты или процессы будут подвергнуты реинжинирингу, для его осуществления выбирается определенная технология (или их набор). В результате выбор объектов реинжиниринга — функция определенной технологии, выбранной для его проведения. Например, если такая технология — это ERP система, то сначала выбирают ERP систему, а только потом МОПы предприятия из тех, которые она может поддерживать. Следовательно, реинжиниринг осуществляет ПО ERR ERP система может преобразовывать все необходимые основные документы (виртуальные или на бумаге) в выбранный вид, так как этот вид задается ПО. В результате реинжиниринг называют «запускаемым технологией». Так как внедрение не меняет ПО, время и стоимость его внедрения при реинжиниринге, «запускаемом технологией», будут ниже.
Реинжиниринг «запускаемый технологией», называли по-разному. Gemini Consulting (1996, с. 7) называет одновременный реинжиниринг и внедрение ERP системы «совместной трансформацией». Технология не только придает определенные возможности реинжинирингу, но и ограничивает его теми опциями, которые может поддерживать ERP система. Таким образом, мы будем называть его также «ограниченным» реинжинирингом.
Реинжиниринг «с чистого листа»
При реинжиниринге «с чистого листа» проектирование системы действительно начинается с «чистого листа». Процессы подвергают-
ся реинжинирингу для удовлетворения нужд и требований предприятия. При использовании этого метода теоретически не существует предопределенных ограничивающих объектов или процессов. В идеале разработчики могут создать систему, оптимальную для конкретной организации. В случае использования ERP систем данный подход предполагает последовательное проведение реинжиниринга, а затем выбор ERP системы. Таким образом, ПО «подстраивается» под организацию, в которой был проведен реинжиниринг; т. е. подстраивается под модель, полученную в результате реинжиниринга «с чистого листа». Так как ПО переделывается под данную модель, затраты на внедрение при этом виде реинжиниринга обычно выше, чем при реинжиниринге1 «запускаемом технологией». Однако при этом новая система должна лучше соответствовать нуждам организации.
Между двумя методами
Во многих проектах реинжиниринга однозначный выбор между реинжинирингом «с чистого листа» и реинжинирингом, «запускаемым технологией», не делается: вместо этого используются они оба. Обычно реинжиниринг проводят или с большим уклоном в сторону либо реинжиниринга «с чистого листа», либо реинжиниринга, «запускаемого технологией», задействуя эти методы в большей или меньшей степени. Это важные вопросы, и мы вернемся к ним в главе 9, в которой обсудим, что должно быть изменено: ПО или организация.
Преимущества реинжиниринга,^запускаемого технологией»
Существует множество преимуществ этого вида реинжиниринга, каждое из которых связано с использованием возможностей технологий, используемых при реинжиниринге. Некоторые из преимуществ использования ERP системы в качестве средства реинжиниринга иллюстрирует случай с компанией Geneva Steel.
ERP обеспечивает идеальную цель для реинжиниринга
Geneva Steel внедрила и использовала SAP в качестве средства изменения информационных потоков для своей реструктуризации. ERP система рассматривалась как технология, которая изменит организацию путем интегрирования БД, улучшения финансовой отчетности, сокращения количества людей и т. д.
Средства, помогающие структурировать усилия по комплексному реинжинирингу
Средства реинжиниринга (например, функционально-стоимостной анализ или ERP) могут предоставить схему развития процессов и объектов, особенно в случае компаний с комплексными процессами. Например, ERP системы обеспечивают справочником, содержащим данные о том, какие виды деятельности используются в каких процессах, как нужно структурировать объекты и т. д. Системы планирования ресурсов предприятий предоставляют пользователю и исходный, и конечный пункты реинжиниринга. Таким образом, такие средства как ERP системы предоставляют структуру, которая может быть важной для успеха реинжиниринга.
Средству помогающие рационализировать и объяснить усилия по реинжинирингу
При использовании в качестве средств реинжиниринга ERP системы также предоставляют «причину» реинжиниринга: «Нам нужно провести реинжиниринг для того, чтобы внедрить SAP». Компания Geneva Steel ясно дала понять, что она будет внедрять SAP, и что это изменит организацию: «Люди, наконец, поняли1 что, нравится это или нет, но это должно случиться». Предполагалось, что внедрение системы SAP обеспечит новую структуру органи- зации.
Средства помогающие создавать решения лучшие, чем были бы созданы иными способами
Системы планирования ресурсов предприятия могут помочь направить усилия по реинжинирингу на принятие лучших решений, мем это можно было бы достичь иными способами. Это происходит в случае, если необходим опыт для принятия лучших решений, а команда развития имеет ограниченный опыт. Лучшие практики, заложенные в ERP системы, дают знание о процессах, которое можно применить, что может смягчить проблему отсутствия опыта. В случае с компанией Geneva Steel система SAP уже была использована большим количеством сталелитейных предприятий. Таким образом, лучшие практики многих из них были заложены в ПО еще до внедрения системы компанией Geneva Steel. Следовательно, Geneva Steel могла найти лучшие решения по сравнению с теми, которые она могла бы принять сама.
Реинжиниринг, <(запускаемый технологией», накладывает ограничения на планирование процессов Реинжиниринг, «запускаемый технологией», ограничивает возможности выбора формы реализации процессов. Если на форму реализации ограничений нет, то может использоваться множество форм, что приведет к информационной перегрузке и трудностям выбора какой-то определенной из них. Без ограничений процессы могут начать сливаться, делая границы между ними нечеткими. Например, границы процессов могут указывать на использование ресурсов, вовлеченность персонала и проектный менеджмент.
Выбранная форма реализации процесса
осуществима данным ПО
Возможно, самой важной причиной использования метода реинжиниринга, «запускаемого технологией», является то, что формы реализации процессов выбираются из числа допустимых. ERP система спроектирована для приспосабливания каждого набора форм. Далее, выбор из заданного набора форм поддерживает проектирование процессов, которые могут взаимодействовать с другими процессами, выбранными для использования в системе. Таким образом, осуществимость критична для конкретных процессов и для их взаимодействия с другими процессами. Например, компания Geneva Steel выбирала лучшие практики из портфеля системы SAP, и это означает, что выбранные формы реализации процессов будут осуществимы.
Есть свидетельство того, что процесс будет работать в организации
Если процесс, соответствующий лучшей практике, является частью ERP системы или другой базы знаний лучших практик, это свидетельство того, что он действительно работает. То, что процесс включен в лучшие практики, обычно означает, что некая организация успешно его внедрила. Это одна из основных причин того, что компания Nestle решила внедрить набор процессов и объектов лучших практик из БД лучших практик, предоставленной консультантом, и из лучших практик компании, содержащихся в ERP системе. Так как система SAP была использована несколькими сталелитейными компаниями, было достаточно свидетельств, что она будет работать и в Geneva Steel.
Процессы могут быть рентабельными
Разработчики систем планирования ресурсов предприятий поняли, что желательно, чтобы при использовании их ПО стоимость
внедрения была разумной. Например, недавняя разработка SAP — «ASAP» направлена на увеличение числа внедрений SAP и рентабельную работу. В целом, затраты на систему, относящиеся к внедрению существующих процессов (например, лучшие практики в ERP системе), могут быть разумными.
Процессы могут быть внедрены в течение конкретного срока
Разработчики также пришли к пониманию важности возможности внедрения ERP системы в течение конкретного срока. Как уже было сказано, компания SAP разработала ASAR нацеленный на то, чтобы внедрения проводились в разумные сроки (например, девять месяцев). Таким образом, многие процессы, предоставляемые ERP, могут быть внедрены в течение приемлемого времени.
Освобождение от множества наслоений
и «размахивающих руками» консультантов
При обсуждении с одной бельгийской компанией выяснилось, что там провели реинжиниринг с применением SAP потому, что были недовольны опытом предыдущей работы консультантов, выдавших большое число предложений и сопроводительных документов на бумаге. Эти предложения не были реализованы по трем основным причинам. Во-первых, хотя идеи были оформлены в форме отчетов, их трудно было преобразовать в форму, которую можно было бы использовать в системе (лучшие практики в ERP системах могут быть внедрены непосредственно). Во-вторых, трудно было оценить осуществимость предложенного, и, наконец, генерирование идей было дорогим.
Программное обеспечение является доступным
Реинжиниринг; «запускаемый технологией», гарантирует, что программное решение будет доступно. В случае с чистым реинжинирингом такой гарантии нет: процессы могут быть разработаны, но может не оказаться ПО, отвечающего их требованиям.
Преимущества реинжиниринга «с чистого листа»
Реинжиниринг «с чистого листа» имеет преимущества по сравнению с реинжинирингом, «запускаемым технологией» (например, ERP), благодаря тому, что он не зависит ни от одной из определенных
технологий. Пример реинжиниринга «с чистого листа» представляет проект «Дельта» компании Geneva Steel (см. приложение 3-1).
Не ограничен ни одним из определенных инструментов
Реинжиниринг «с чистого листа» не ограничен ни одним из определенных инструментов. Например, проект «Дельта» компании Geneva Steel не имел при внедрении каких-то начальных предпочтений, так как не было инструментов, способствующих реинжинирингу. Таким образом, при реинжиниринге «с чистого листа» для внедрения может быть использован целый набор инструментов. Так как любое средство реинжиниринга накладывает ограничения и привносит определенные предпочтения, использование нескольких средств может иметь значительные преимущества по сравнению с использованием одного единственного инструмента.
Не ограничен знанием о событиях и процессах
Хотя ERP системы могут использовать ряд лучших практик, они также ограничены своей БД лучших практик. Фирмы, имеющие уникальные процессы, создающие ценность, часто следят за тем, чтобы они не были включены в число процессов, которые попадают в БД консультантов или ERP системы. Из обсуждения с компанией Price Waterhouse выяснилось, что некоторые из их клиентов попросили, чтобы информация об их лучших практиках не включалась в БД лучших практик. Некоторые клиенты даже попросили компанию Price Waterhouse исключить общедоступные знания из этих БД. Таким образом, когда организация использует БД лучших практик, та может включать вовсе не все лучшие практики.
Будущие версии не обязательно ограничиваются изменениями в конкретной технологии
Со временем процессы непременно развиваются. Эти изменения базируются на большом числе факторов, включая первоначальный старт. Обычно, чем первоначальный старт лучше, тем меньше необходимость изменения процесса во времени. Если форма реализации процесса опирается на «запуск технологией», а технология меняется, это может привести к ущербу для фирмы, проводившей подобный реинжиниринг Поэтому, если пользователи ERP заинтересованы в том, чтобы их система развивалась эффективно, им приходится «вкладываться» в будущие версии ПО. В противном случае при переходе к другой системе потребуются большие затраты на установку.
Разработка формы реализации процесса, к которому другие не имеют прямого доступа
Метод реинжиниринга «с чистого листа» позволяет фирмам думать «вне коробки» . В этом случае фирмы могут создать новые подходы к решению проблем. Это особенно важно в обстановке, когда реинжиниринг может обеспечить конкурентное преимущество (а не помочь в ликвидации отставания). Тем фирмам, в которых технология используется в качестве конкурентного преимущества, реинжиниринг «с чистого листа» может обеспечить дополнительное преимущество. При осуществлении реинжиниринга «с чистого листа» только развивающаяся фирма знает форму реализации процессов. Если вместо этого используются существующие лучшие практики, фирмы вынуждены просто «подхватывать игру».
Реинжиниринг рассматривается отдельно
от внедрения технологии
Часто внедрение ERP систем критиковали за то, что оно слишком дорого и требует слишком большого времени. В некоторых ситуациях эти недостатки возникают не собственно из-за внедрения ERR а из-за того, что сюда включается и внедрение ПО, и реинжиниринг При проведении реинжиниринга «с чистого листа» нет сомнений, где ——реинжиниринг; а где ——внедрение технологии.
Исследование реинжиниринга бизнес-процессов (BPR) и ERR проведенное Gemini Consulting (1996), показало, что только 16% рассмотренных фирм планировали провести реинжиниринг бизнес-процессов до внедрения ERP системы. Однако после внедрения 35% фирм сказали, что стоит использовать стратегию проведения реинжиниринга бизнес-процессов до внедрения ERR Таким образом, существует свидетельство того, что фирмы нуждаются в первоначальном проведении реинжиниринга и только затем ——во внедрении ERR
Реинжиниринг «с чистого листа» может быть единственным выходом для внедрения процессов в новые технологии
В некоторых случаях процессы должны быть включены в «контекст» новых технологий — например, Интернет или сканирование штрих-кода ——когда они становятся доступными. При использовании
* Имеется в виду, не быть привязанной к конкретному программному продукту (прим. науч, редактора).
таких технологий может быть мало понятно или вообще не понятно, что является лучшей практикой. Так как не совсем понятно, как поддерживающие процессы должны работать в рамках новых техноло- гий5 реинжиниринг «с чистого листа» в этих случаях может быть единственным возможным подходом.
Недостатки реинжиниринга,«запускаемого технологией»
Недостатки реинжиниринга, «запускаемого технологией», по большей части, прямо противоположны преимуществам подхода к реинжинирингу «с чистого листа». Так как они уже подробно обсуждались, вышеупомянутые недостатки здесь просто перечислены.
Реинжиниринг ограничен определенным инструментом, использованным при внедрении.
Реинжиниринг ограничен знанием об объектах и процессах, включенных в инструмент.
Развитие системы может ограничиваться технологией.
К выбранной форме реализации процессов имеют доступ другие фирмы.
могут появляться сомнения: это внедрение технологии или реинжиниринг?
Для некоторых установок может не оказаться лучших практик, что ограничивает их использование.
Недостатки реинжиниринга «с чистого листа»
Недостатки реинжиниринга «с чистого листа», по сути, прямо противоположны преимуществам метода реинжиниринга, «запускаемого технологией». Так как о них мы уже говорили подробно, достаточно только перечисления.
Может не оказаться структуры, помогающей создать формы реализации процесса.
Нет рациональных оснований для реинжиниринга.
Процессы могут оказаться оптимальными лишь частично.
нет ограничений для исходной формы реализации процесса.
Выбранная форма реализации процесса может оказаться недопустимой.
Процесс в избранной форме реализации может не работать с выбранной ERP системой.
Могут потребоваться дополнительные денежные и временные затраты на развитие и внедрение выбранной формы реализации процесса.
Придется задействовать многочисленных консультантов и кучу отчетов об их работе.
Может не оказаться необходимого ПО.
Кто должен использовать (или использует) методреинжиниринга «с чистого листа»?
Какие фирмы должны использовать метод реинжиниринга «с чистого листа», а какие —— реинжиниринг, «запускаемый технологией»? Ответ зависит от нескольких факторов, включая размер фирмы, объем средств, которые она может вложить в развитие новых процессов, располагает ли фирма достаточным количеством времени на создание процессов, степень зависимости фирмы от технологии для создания конкурентного преимущества и используются ли в фирме какие-то уникальные процессы.
Крупные фирмы
Размер фирмы влияет на использование метода реинжиниринга «с чистого листа» ——более крупные фирмы имеют большое число причин для использования данной стратегии. Они:
Имеют ресурсы для осуществления такого реинжиниринга.
Часто являются лидерами в своей сфере и, как следствие, имеют запас во времени.
Существует большая вероятность, что они будут использовать процессы в качестве базиса для получения стратегического преимущества.
Существует большая вероятность того, что им понадобится уникальное решение.
Фирмы с《большими карманами»
Реинжиниринг «с чистого листа» требует значительных ресурсов, так как он не использует возможности или информацию, которую могут предоставить лучшие практики ERP систем. Кроме того, чтобы провести реинжиниринг «с чистого листа», фирма должна иметь ресурсы для создания новых процессов и объектов. Инновации также требуют учас-
тия особо высококвалифицированных специалистов, которые иначе могли бы заниматься другими видами корпоративной деятельности.
Компания Procter & Gamble продемонстрировала важность «больших карманов» в рамках своей работы по осуществлению реинжиниринга процессов управления цепочками поставок (см. McKenney and Clark 1995). Procter & Gamble использовала большое число различных форм реализации процессов в ряде компаний-клиентов для развития своей системы управления цепочками поставок, которую она, в конечном итоге，отдала компании IBM. Начав с обмена электронными данными, Procter & Gamble развила систему, в которой она осуществляла мониторинг запасов клиентов и размещала заказы для них, используя прямое обращение к их БД. Такая эволюция потребовала много времени и вложений и оказалась бы невозможной без значительных ресурсов.
Фирмы, имеющие запас времени
Имеющееся в распоряжении фирмы время на внедрение ERP системы может зависеть от большого числа факторов, в том числе от мотивов ее внедрения. В случае с компанией Quantum модель ERP была выбрана для внедрения с целью повышения конкурентоспособности при работе с клиентами. Клиенты не могли ждать, пока Quantum ответит на их заявки, и компания, таким образом, теряла клиентов. Компьютерные жесткие диски обеспечивали преимущест- во, и Quantum была заинтересована в поиске клиентского сервиса, который обеспечил бы достижение конкурентного преимущества. Она нуждалась в интеграции ее предприятий и поставщиков во всем мире, следовательно, она была ограничена во времени для проведения реинжиниринга «с чистого листа». В результате компания использовала метод реинжиниринга, «запускаемого технологией».
Фирмы, в которых процессы используются для создания стратегического преимущества Фирмы могут добиться конкурентного преимущества, или создав лучшие процессы, или внедрив существующие процессы лучше, чем другие фирмы. Если фирмы используют существующие процессы, не важно, являются они лучшими практиками или нет — они в конечном итоге выбирают конкурентную борьбу, основанную на внедрении этих процессов.
Чем более уникальна фирма с точки зрения ее производства, процессов, клиентов или множества других факторов, тем более вероятно, что они не будут заинтересованы в использовании процес-
сов или объектов других компаний, которые будут доступны при реинжиниринге, «запускаемом технологией». Вместо этого, чтобы приспособиться к своим уникальным процессам, фирмы, возможно, посчитают необходимым использовать метод реинжиниринга «с чистого листа».
Фирмы, ищущие уникальное решение
Решения реинжиниринга, «запускаемого технологией», могут быть скопированы другими, и лучшие практики ERP систем, внедренные в одной фирме, могут быть реализованы и в других фирмах. Напротив, решения реинжиниринга «с чистого листа» обычно распространяются не так быстро. Если организации нужно уникальное решение, то его скорее предоставит реинжиниринг «с чистого листа».
Кто должен использовать (использует)метод реинжиниринга, «запускаемого технологией»?
Факторы, о которых мы говорили выше, могут также использоваться для определения того, какие фирмы должны применять решения, «запускаемые технологией». Например, малые фирмы обычно имеют небольшие бюджеты и стандартные процессы, которые ограничивают их способность и необходимость проводить большой реинжиниринг «с чистого листа». Так, компания Accugraph (см. Koch 1996) внедрила «предварительно структурированный» пакет компании SAP «Special Delivery». Она сосредоточилась на финансовом пакете, консультантах и отказалась от какого-либо реинжиниринга вне возможностей наперед указанных форм реализации процессов.
Какой подход используют чаще всего?
В исследовании Gemini Consulting (1996) была собрана эмпирическая информация по одновременному и не одновременному осуществлению реинжиниринга бизнес-процессов и внедрения SAR Фирмам были заданы вопросы о (а) реально использованной стратегии и (б) о том, какую стратегию они выбрали бы, если бы могли начать заново. Хотя данные относятся к определенной системе (SAP), результаты могут быть распространены и на другие ERP системы. Результаты исследования представлены в таблице 6.2,
Таблица 6.2. Реинжиниринг бизнес-процессов и SAP R/3
Список А: Оригинальная стратегия внедрения
BPR и одновременное внедрение SAP R/348%
BPR до внедрения SAP R/316%
BPR после внедрения SAP R/33%
BPR до 锵 после внедрения SAP R/31 %
BPR не был нужен33%
51%35%3%1%10%51%35%3%1%10%Список Б: Что бы вы выбрали после внедрения?
51%
35%
3%
1%
10%
51%
35%
3%
1%
10%
BPR и одновременное внедрение SAP R/3
BPR до внедрения SAP R/3
BPR после внедрения SAP R/3
BPR до и после внедрения SAP R/3
BPR не был нужен
Источник: Gemini Consulting (1996).
Gemini Consulting установила, что в обоих случаях только 4% компаний либо осуществляли, либо захотели бы в результате полученного опыта осуществить реинжиниринг бизнес-процессов после внедрения SAP или до и после внедрения. Напротив, 96% или не осуществляли реинжиниринг вообще, или делали это до внедрения SAR или одновременно с внедрением. Только 16% запланировали реинжиниринг до внедрения SAR а позже 35% говорили, что они выбрали бы эту стратегию. И в списке А, и в списке Б реинжиниринп «запускаемый технологией», является доминирующей стратегией. При сравнении списков А и Б видно, что самый большой рост происходит в пользу выбора реинжиниринга «с чистого листа». Самым же значительным образом уменьшилось число фирм (с 35% до 10%), считающих, что реинжиниринг не нужен. Таким образом, видно, что фирмы должны предусматривать проведение реинжиниринга при внедрении такой ERP системы, как R/3.
Резюме
В данной главе были исследованы реинжиниринг «с чистого листа» и реинжиниринг; «запускаемый технологией». Преимущества реинжиниринга «с чистого листа»:
Фирмы не ограничены конкретными инструментами.
Фирмы не ограничены отсутствием знаний о лучших практиках.
Будущие версии не ограничиваются технологиями.
Фирмы могут создать уникальные формы реализации процессов.
Реинжиниринг не смешивается с внедрением технологии.
Он может быть единственным выходом для создания процессов при использовании новых технологий.
С другой стороны, реинжиниринг, «запускаемый технологией», может:
структурировать усилия по реинжинирингу,
рационализировать и объяснить необходимость приложения усилий по реинжинирингу,
создавать лучшие решения,
ограничить форму реализации процессов,
ограничить усилия по поиску формы реализации процессов,
гарантировать, что выбранная форма реализации процессов будет работать,
создать более рентабельные формы реализации процессов1
гарантировать внедрение, ограниченное во времени,
помочь фирмам избежать необходимости использования множества консультантов с их отчетами.
Предприятия должны выбрать метод, соответствующий их потребностям и ресурсам в процессе реинжиниринга. В целом, можно предположить, что фирмы, использующие метод реинжиниринга «с чистого листа», кроме того, что они крупные, имеют также «большие карманы», не имеют ограничений во времени и имеют или используют уникальные процессы в качестве основы конкурентного преимущества. Напротив, использование метода реинжиниринга, «запускаемого технологией» более характерно для фирм:
с ограниченным бюджетом,
ограниченных во времени,
с относительно стандартными процессами.
В любом случае фирмы должны понимать, что некоторый реинжиниринг будет необходим. Одно из исследований показало, что большинство фирм выбрали одновременный реинжиниринг и внедрение ERP системы, т. е. метод реинжиниринга, «запускаемого технологией».
Литература
CSC Index (1994). State of Reengineering Report. Boston: CSC Index.
Gemini Consulting (1996). «Business Leader's Experience with SAP
Implementation», Gemini Consulting, Hamburg, Germany.
Gendron,M. (1996). «Learning to Live with the Electronic Embodiment of Reengineering». Harvard Management Update, November, pp. 3-4.
Hammer, M. (1990). «Reengineering Work: DonJt Automate, Obliterate». Harvard Business Review, July/August，PR 104-12.
Hammer M, (1997) Reengineering, SAP and Business Processes Unpublished presentation given at SAPphire (ОПапбо3 FL), August.
Koch,C. (1996). «Flipping the Switch». CIO Magazine, June 15.
McKenney, J., and Clark,工(1995). «Procter & Gamble: Improving Consumer Value through Process Redesign». Report no. 9-195-126, Harvard Business School, Cambridge, MA.
Часть третья
ЖИЗНЕННЫЙ ЦИКЛ ERP СИСТЕМ
7 ПРИНЯТИЕ РЕШЕНИЯ О ВНЕДРЕНИИ ERP СИСТЕМЫ
В данной главе анализируются различные случаи, ассоциируемые с .принятием решения по внедрению ERP системы. В частности здесь исследуются следующие четыре вопроса:
Какими могут быть бизнес-основания, определяющие, внедрять или не внедрять ERP систему, и какие из них являются наиболее распространенными?
Как можно использовать бизнес-основания для облегчения разработки формы реализации процессов или оценки успешности внедрения?
Как фирмы оценивают основания: в денежном или в ином выражении?
Как в конечном итоге фирма принимает решение о внедрении ERP системы?
Бизнес-основания
Бизнес-основания для принятия решения о внедрении ERP системы можно объединить в четыре категории: технология, бизнес- процессы, стратегия и конкуренция. Каждая из этих категорий оснований имеет свои ограничения. Данная глава иллюстрирует случаи применительно к каждой категории.
Выбор бизнес-оснований важен, по крайней мере, по трем причинам. Во-первых, тщательный анализ необходим для того, чтобы гарантировать, что фирма принимает правильное решение относительно ERP системы. В конечном счете этот анализ может породить различные обоснования или доводы, используемые для доказательства необходимости внедрения ERP системы. Во-вторых, в некоторых случаях основания для выбора могут помочь при разработке «конструкции» ERP системы, обеспечивая ее специфичность. Например, если целью является улучшение определенного процесса, степень этого улучшения может быть измерена. В-третьих, базис для выбора может облегчить оценку успешности внедрения в зависимости от достигнутой степени соответствия бизнес-основаниям. Для определения успешности внедрения могут использоваться различные методы оценки.
Технологические обстоятельства
Организации использовали множество технологических оснований для оправдания выбора ERP системы. В проведенном недавно исследовании компании Deloitte & Touche фирмам был задан вопрос, почему они решили внедрить ERP систему. Результаты исследования представлены в таблице 7.1.
Таблица 7.1. Технологические мотивы
Мотив
Число фирм
Процент от общего числе
Системы не решают «Проблемы 2000-го года»
42
27
Несопоставимые системы
37
24
Низкое качество систем / представления информации
26
17
Бизнес-процессы или системы не интегрированы
19
12
Трудности интеграции приобретенных компаний
12
8
Устаревшие системы
11
7
Невозможность поддерживать рост
8
5
При этом фирмы смогли назвать не одну причину и положительный результат внедрения. В данном параграфе мы рассматриваем различные технологические основания, используя для иллюстрации примеры этой мотивации.
«Проблема 2000то года»
Одной из наиболее распространенных причин адаптации ERP-систем была «Проблема 2000-го года» («Y2K»). Фирмы столкнулись с необходимостью модернизировать традиционные программы, чтобы избежать возможных сложностей, вызванных «Проблемой 2000-го года». Во многих случаях эта задача оказалась трудноразрешимой. Так как программисты уже не работали, а достаточной документации по программам не было, о многих из этих систем было мало что известно. Кроме того, речь шла о сотнях программ.
Системы планирования ресурсов предприятий, казалось, предлагают относительно быстрое и простое решение для многих фирм. Такие пакеты программ, как SAR могли решить «Проблему 2000-го года», так что при внедрении определенных ERP систем многих проблем можно было бы избежать. Во многих случаях ERP системы предлагали выгодное в финансовом отношении решение «Проблемы 2000-го года». Внедряя ERP систему, фирмам не нужно было тратить миллионы долларов, не улучшая при этом существующие решения.
Пример. Из разговора с Барри Сейдом, заместителем директора компании Litton Data Systems, мы узнали, что «Проблема 2000-го года» была движущей силой в «продаже идеи» ERP руководству компаний. Как рассказал Сейд:
Мы действительно продали [ERP] из-за «Проблемы 2000 года»... Если у вас системы 20-, 25-, 30-летней давности, то, по оценкам Gartner Group, вам придется потратить от 1,10 до 1,65 доллара за каждую строку программного кода для изменений в связи с «Проблемой 2000-го года». Если у вас 4 000 000 строк, то речь идет об очень больших деньгах. Кроме того, это не все, что касается традиционных систем ——их некому обслуживать, их никто не понимает. Таким образом, чтобы настроить их так, чтобы они могли работать в 2000 п} вам потребуются миллионы и миллионы долларов, а риск будет большим. По сути, мы продавали эту систему, базируясь на «Проблеме 2000-го года».
Несопоставимые системы
Несопоставимые компьютерные среды ограничивают возможность фирм интегрировать различные бизнес-единицы, деятельность которых поддерживается различными типами компьютеров. ERP системы предоставляют широкий выбор ПО для работы в единой вычислительной среде.
Более того, многие фирмы перешли на технологию клиент-сервер для того, чтобы покончить с системами на основе мейнфрейма и сопутствующими технологиями (см. например, Vaughn 1996). Чтобы они смогли это реализовать, им понадобилось «клиент-серверное» ПО. Однако, совершив переход к технологии клиент-сервер в начале 90-х гп, фирмы обнаружили, что ПО для работы в этой среде было мало доступным. Среди ограниченного числа доступных программных продуктов были ERP системы, такие как SAP R/3.
Примеры. Конфигурация информационной системы компании Geneva Steel со временем эволюционировала в несколько неоднородных систем. Как сказал Джозеф Кеннон (СЕО компании Geneva Steel):
У нас есть... мейнфрейм ... и ... примитивная бухгалтерская система ...
У нас много различных типов компьютеров. Им сложно общаться друг с другом. У нас большое количество мини-компьютеров различных типов с различным программным обеспечением ... Наша система —это выход из этого ада.
Приведем другой пример (Stevens 1998): компания Owens Corning перешла к стандартной клиент-серверной архитектуре, используя интернет-протоколы (IP) и имеющееся в наличии готовое ПО с целью уменьшения стоимости системы и владения сетью. Это бизнес-основание было использовано компанией Owens Corning наряду с другими основаниями, описанными ниже.
Низкое качество существующих систем
Некоторые компании выбрали ERP систему, так как их существующие системы имели низкое качество, и интегрированная ERP система была единственной возможностью для улучшения ситуации. Существующие системы или вышли из строя, или были близки к этому, что вынудило фирмы рассматривать другие варианты.
Примеры. Явная неспособность систем, которые использовались в компании Microsoft, соответствовать предъявляемым к ним требованиям привела компанию к решению внедрить ERP систему.
Например, как заметил Джон Коннорс, бывший корпоративным управляющим компании Microsoft, когда она решила внедрить SAP:
У нас был очень плохой процесс бюджетирования. Группа информационных технологий и финансовое подразделение разработали новую программу для бюджетирования, но она не работала... Дело было серьезно... Я только что вернулся из отпуска, а Стив Баллмер только что приехал из компании Wal-Mart. Стив постучался и открыл дверь моего кабинета. Я уже знал, что это был Стив, он всегда стучался по-особенному. Он вошел и сказал: «Вы издеваетесь [ненормативная лексика опущена]!» Я его понял. (Bashein, Markus, and Finley 1997)
Адаптация ERP системы Oracle компанией Cisco (см. Cotteleer, Austin, and Nolan 1998) была также вызвана выходом из строя системы.
В январе 1994 匚 традиционная система компании Cisco дала столь серьезный сбой, что дефекты имеющихся систем уже невозможно было дальше игнорировать. Несанкционированный метод доступа к ядру БД приложений ——обходной путь, выбранный из-за неспособности системы работать,——не сработал, испортив центральную БД компании. В результате большая часть Cisco прекратила работу на два дня. Попытки Cisco оправиться от того, что произошло, сделали ясным тот факт, что системы компании были на грани полного отказа.
Трудности интегрирования приобретенных компаний
Приобретение несопоставимых компаний может оказывать большое напряжение на информационную систему фирмы. Различие в системах может усложнять сравнение трудностей подразделений, что в свою очередь усложняет распределение ресурсов. Кроме того, различные процессы, сосуществующие в этих системах, могут помешать получению положительного эффекта от изменения масштабов деятельности компании, и различные системы и процессы могут сделать взаимодействие ее подразделений проблематичным. Таким образом, в некоторых случаях фирмы решают внедрить ERP системы для облегчении интеграции приобретенных компаний.
Пример. Как рассказал Стефан Ютоф, вице-президент по планированию компании Browning-Ferris:
Нам нужно было видеть, как работают наши процессы... Процессы должны меняться. Как компания, приобретшая множество других компаний, Browning-Ferris не имела унифицированных процессов. Одной из стоящих перед нами задач было сделать так, чтобы 500 наших подразделений использовали стандартные процедуры. (Bailey 1999)
Оценка технических оснований
Несмотря на все их количество, технические основания обычно можно сделать измеримыми на уровне ответов «да-нет». Например, справляется приложение с «Проблемой 2000-го года» или нет; можно интегрировать сбор данных или нет; могут системы поддерживать рост или нет. Технические основания могут быть достаточными для замены системы, но они мало говорят о том, какая конфигурация системы нужна.
Основания со стороны бизнес-процессов
Организации использовали несколько оснований со стороны биз- нес-процессов для оправдания выбора ERP системы. Например, организация могла бы назвать потенциальной причиной перехода к ERP системе сокращение незавершенного производства на 40%. В исследовании, проведенном Deloitte and Touche, фирмы также спрашивали, какие изменения в бизнес-процессах помогают определить необходимость внедрения ERP системы. Основания со стороны бизнес-про- цессов, по большей части, состоят в улучшении продуктивности организации или снижении расходов. Результаты исследования представлены в таблице 7.2. При этом фирмы смогли назвать не одну причину и положительный результат внедрения. В дополнение к этой таблице в данном параграфе обеспечивается «погружение в данные» множества бизнес-оснований и приводятся конкретные примеры.
Таблица 7.2. Ожидаемые бизнес-преимущества от внедрения ERP
Преимущество
Кол-во фирм
Процент от общего числа
Сокращение персонала
44
20
Сокращение запасов
42
19
Сокращение расходов на ИТ
27
13
Повышение производительности
23
11
Сокращение цикла управления заказами
19
9
Управление денежными средствами
16
7
Прибыль/доход
15
7
Снабжение
12
6
Завершение финансового цикла
10
5
Техническое обслуживание
8
4
Сокращение персонала и расходов на ИТ
Внедрение ERP систем часто связывают с последующим сокращением персонала, особенно в бухгалтерии и подразделениях информационных систем.
Пример. Ожидается, что внедрение SAP компанией Geneva Steel отразится на количестве бухгалтеров и персонала подразделения информационных систем. Как сказал СЕО компании Джозеф Кеннон:
В первую очередь, у нас будет меньше бухгалтеров и, возможно, меньше администраторов информационных систем. Потому что одна из вещей, которые мы рассматриваем, это сокращение части этих функций. Большую часть того, что делают бухгалтеры ... не нужно будет делать, когда будет внедрена система SAR
В результате компания Geneva Steel предполагала сократить свой штат сотрудников отдела информационных технологий примерно с 80 до 12 человек, а штат бухгалтерии с 60 до 10 человек.
Повышение производительности
Шаф (Schaff 1997) заметил, что, так как повышение производительности всегда будет в моде, разработчики ERP будут иметь постоянный спрос на свою продукцию. Не удивительно, что некоторые фирмы принимают решение о внедрении ERP системы с целью улучшения конкретных аспектов производительности.
Пример. Компания Owens Corning приняла решение о внедрении ERP системы с целью повышения производительности. Как отметил Майкл Редклиф (вице-президент по интернет-обслуживанию и СЮ компании Owens Corning), когда проект внедрения ERP начался: «Чтобы оправдать [затраты на] проект, мы изначально нацелились на ощутимые результаты, которые руководство сможет увидеть и которые мы сможем четко сформулировать и выполнить» (см. Stevens 1998). Ожидалось, что доходы от внедрения достигнут 50 млн. долларов, в том числе, благодаря:
уменьшению расходов на 1 % при закупках сырья благодаря положительному эффекту масштаба;
уменьшению расходов на 1% благодаря сокращению количества складов и более низкой стоимости перевозок;
улучшению обслуживания, ориентированного на обеспечение надежности, что обеспечит меньшие расходы на обслуживание предприятия.
Завершение финансового цикла
Чтобы обеспечить качество управленческих решений, необходима своевременная информация. Одним из основных средств в этом направлении является количество времени, требующегося на завершение финансового цикла. Таким образом, сокращение времени на завершение финансового цикла может стать важной причиной внедрения ERP системы. Например, компания X (см. приложение 12-1) хотела при внедрении ERP системы сократить ежемесячный процесс завершения финансового цикла с 24 до 6 дней.
Оценка оснований со стороны бизнес-процессов
В отличие от технических оснований основания со стороны биз- нес-процессов могут потребовать специальной оценки для определения того, принесет ERP система пользу или нет. Кроме того, конкретные основания со стороны бизнес-процессов могут помочь при создании «конструкции» системы и в процессе оценки, о чем рассказывается ниже, а также в главе 12.
Прогнозирование при оценке, возможно, будет зависеть от того, какой метод реинжиниринга использовался: «с чистого листа» или «запускаемый технологией». Если бьт осуществлен реинжиниринг «с чистого листа», результаты будет определить трудно. Однако если проводился реинжиниринг; «запускаемый технологией» ERR для определения результатов может быть использован опыт других фирм.
Стратегические основания
Системы планирования ресурсов предприятий предоставляют возможность внедрения различных стратегий, которые существующее ПО не подцерживает. Эти стратегии выходят за рамки улучшения конкретных бизнес-процессов. Стратегические основания позволяют сфокусироваться на целях улучшения уровня обслуживания клиентов или качества вообще — вопросах, обычно не связываемых с системами обработки деловых операций. Стратегические основания могут привести к внедрению ERP системы как информационной магистрали, которая может быть использована в качестве базиса электронной коммерции. Эти вопросы рассмотрены в главе 14.
Примеры. Чтобы повысить уровень обслуживания клиентов, компания Quantum выбрала Oracle Applications. Решение о внедрении ERP системы было основано на том, что система могла выполнить эту клиенто-ориентированную стратегию, и на конкретных возможностях системы.
Приведем дру「оМ пример. Компания Cisco также смотрит на затраты на ИТ с точки зрения стратегии. Как сказал президент компании Джон Могридж: «Мы с самого начала не думали об их [ИТ] возможностях в терминах долларов. Мы считали, что необходимо обеспечить качественное обслуживание, и именно поэтому мы внедрили программу» (Stevens 1998).
Конкурентные основания
Хотя технологические основания и основания со стороны биз- нес-процессов важны, одна из основных причин внедрения ERP системы —это то, что у конкурентов она уже есть. Как сказал Брюс Ричардсон из AMR Research: «ERP часто покупают для того, чтобы просто остаться в бизнесе».
Если у конкурентов есть ERP система, а у вас — нет, они могут иметь (например) более лучшие возможности для обслуживания клиентов или быстрее снабжать информацией своих менеджеров, особенно если они решат внедрить систему для достижения именно этой цели. Таким образом, принятие на вооружение ERP системы одной фирмой может привести к необходимости для ее прямых конкурентов вооружиться подобной системой.
Заявление «у конкурентов это есть» в качестве основания может породить, по крайней мере, два абсолютно разных подхо~ да. С одной стороны, фирма может просто заявить, что у ее основных конкурентов система есть, и поэтому у нее она тоже должна быть. С другой стороны, фирма может остановиться на вопросе, почему важно то, что у конкурентов есть именно эта система, и исследовать, какие специфические выгоды могут быть получены при аналогичном выборе.
Пример. Предположим, что ваша фирма — конкурент компании Quantum, которая решила внедрить ERP систему, чтобы повысить уровень обслуживания клиентов. В частности, ERP позволяет ей обеспечивать клиентам опцию «доступно по обещанию» (available to promise, АГР) — уникальную возможность, которая позволила компании гарантировать, что запасы могут быть распределены между конкретными покупателями (обычно между самыми крупными и лучшими покупателями). Так как Quantum вооружилась системой раньше, вы как конкурент могли бы просто наблюдать, было ли внедрение 口ро「раммн успешным и работает ли АТР так, как предполагалось. Когда ПО заработало, вы могли подумать о его внедрении в своей фирме, чтобы предоставить клиентам те же возможности.
Компания Western Digital — один из основных конкурентов компании Quantum. 24 июня 1996 г. отдел прикладных систем корпорации Oracle объявил, что «несколько компаний работали с Oracle Applications в течение квартала, включая Silicon Graphics, Inc. и корпорацию Quantum, причем обе эти компании успешно провели крупномасштабные внедрения». Кроме того, в это же время отдел прикладных систем корпорации Oracle объявил, что «среди новых клиентов, появившихся за этот квартал,... компания Western Digital...»
Использование бизнес-оснований
для определения «конструкции» и оценки успеха
В некоторых случаях в качестве основы для принятия решений могут использоваться бизнес-основания. Кроме то「о, они могут быть использованы и для оценки успешности внедрения (этот вопрос рассматривается в главе 10).
Основание, использовавшееся как советчик при принятии решения о внедрении ERP системы, может быть использовано и как советчик при выборе формы реализации процессов. Если решения ° внедрении ERP системы базировались на эффективности биз- нес-процессов или выборе страте「ии, то можно собрать информацию, необходимую для определения того, каким должен быть «конструктив» системы, базирующейся на этих основаниях. Если ERP внедряется для поддержки конкретной стратегии, то процессы мо“ 「ут быть спроектированы для достижения совершенства реализации этой стратегии. Например, если в основе решения о внедрении лежит улучшение материальнс“техническо「о снабжения, то процессы должны быть спроектированы конкретно для достижения этой цели.
Однако если выбор ERP базируется на технологических основаниях (таких, как необходимость иметь ПО для работы в среде клиент-сервер или для решения «Проблемы 2000-「о года») или на резонах, связанных с конкуренцией (скажем, чтобы просто остаться в бизнесе), то они мало чем могут помочь в проектировании процессов. Явных критериев выбора формы реализации процессов, связанных с этими основаниями, не существует. Таким образом, основания со стороны стратегии и продуктивности более надежны с точки зрения их вклада в процесс разработки формы реализации процессов.
Метод чистой приведенной стоимости(Net present value, NPV)
Хотя ранее каждая категория оснований была рассмотрена отдельно, для анализа всех расходов и выгод, как и при любом инвестировании, может быть использован метод NPV. Bern (Wagle 1998, с. 132) предлагает для этого следующие шаги:
Смоделировать ежегодную экономию средств от сокращения расходов, которая могла бы быть достигнута без использования на предприятии ERP системы в качестве базовой.
Смоделировать ежегодную экономию средств, которая могла бы быть достигнута с использованием ERR Сюда должны быть включены сэкономленные средства, как не зависящие от ERP системы (случай шага 1),так и те, которые экономятся благодаря ее использованию.
Вычесть ежегодную экономию средств для случая шага 1 из экономии средств для случая шага 2 (с ERP) и рассчитать NPV остаточного движения денежных средств. Положительное значение NPV укажет на то, что вы, вероятно, должны продолжить внедрение ERP.
Если на шаге 3 получена положительная NPV, проведите анализ чувствительности, чтобы убедиться в том, что бизнес-доводы достаточно устойчивы, чтобы противостоять уменьшению и перерасходу средств.
Перераспределите все расходы на внедрение ERP системы между конкретными бизнес-единицами, чтобы они могли включить их в свои планы. Убедитесь, что каждая бизнес-единица несет ответственность за реализацию намеченных изменений.
Оценка оснований: денежные цели против неденежных
Независимо от вида бизнес-основания для решения о внедрении ERP системы многим фирмам требуется некоторая внутренняя оценка (денежная или неденежная) затрат и выгод от ее внедрения.
Цели, оцениваемые в денежном выражении
Очевидно, что высший менеджмент и совет директоров компании предпочтут оценку ERP в терминах целей, оцениваемых в денежном выражении. Как сказал Майкл Редклиф, когда компания Owens Corning начала внедрение ERP (см. Stevens 1998):
[ERP] будет стоить много денег и привлечет внимание совета директоров. Поначалу мы рассуждали о разумности, стратегии, сотрудничестве, интуиции и дальновидности, но в конечном итоге мы пришли к долларам и центам.
Целиг не оцениваемые в денежном выражении
Некоторые фирмы (такие, как Cisco), обращающие основное внимание на стратегии, при оценке потенциальных инвестиций в ERP системы не говорят о деньгах. Например, как сказал Питер Солвик (СЮ компании Cisco):
Компании, которые оправдывают осуществление ИТ-проектов, ориентируясь, прежде всего, на ROI, возможно не используют системы стратегически... У нас измеримые цели, но они не измеряются в долларах,——это такие вещи, как удовлетворенность клиентов, сокращение времени на закрытие бухгалтерских книг; более быстрое предоставление отчетов менеджерам или более быстрая доставка товаров клиентам (Stevens 1998).
Как фирма в конечном счете решает,внедрять или не внедрять ERP?
Многие фирмы, приведенные в качестве примеров, рассмотренных в данной главе (например, Litton Data Systems и Owens Corning), использовали для принятия решения о внедрении ERP системы анализ рентабельности. Однако он может помочь скорее не в принятии решения, а в его объяснении. Например, некоторые консультанты утверждали, что оценка ROI, связанная с различными основаниями и ERP системами, не является в целом возможной, — неважно в денежном или в неденежном выражении. Как сказал Брюс Ричардсон, вице-президент AMR: «Никто еще не смо「продемонстрировать окупаемость ERP».
Такое мнение могло возникнуть в результате рассмотрения других вопросов. Например, это утверждение могло быть результатом
качества оцениваемых данных (например, достоверные и недостоверные данные). Оно также могло быть результатом того, как используется оценка. В-третьих, конкретного подхода требует культура организации.
Достоверные данные против недостоверных
«Качество» данных, на которых строится основание выбора, может зависеть от вида основания, создающего данные оценки. Например, как сказал Барри Сейд из компании Litton Data Systems: «Я сделал так, чтобы наши служащие шире изучали ROI [на различных аспектах повышения производительности],... но это были недостоверные данные».
Кроме того, на покупку системы корпорацией может повлиять качество данных. Как сказал Сейд: «Данные о «Проблеме 2000-го года» были достоверными. Они [топ менеджмент] поверили этим данным».
Использование оценки
Как видно из примера компании Litton Data Systems, измерение затрат и результатов было основано на текущем ERP-проекте. Однако в некоторых случаях ROI используется как ориентир для других проектных инвестиций. Джон Мортридж (глава компании Cisco) отметил: «Обычно мы не выполняем традиционный анализ ROI до осуществления инвестиций и запуска ИТ-программы. Мы изучаем ROI после инвестиций и используем это как ориентир для направления и размеров будущих инвестиций в ИТ» (Stevens 1998).
В любом случае, оценка проектных расходов необходима для того, чтобы оценить общую успешность внедрения и обеспечить «актуальность» начального бюджета. Эти проектные затраты должны начинаться с расходов на принятие решения «стоит или нет внедрять ERP систему» и продолжаться в течение всего жизненного цикла проекта.
Организационная культура
Организационная культура может потребовать детального предварительного финансового и нефинансового анализа проекта. С другой стороны, можно сфокусироваться на апостериорном анализе, который, в свою очередь, может быть использован в будущих технологических проектах. К сожалению, оценка преимуществ может быть нечеткой и непредсказуемой; а расходы завуалированными или скрытыми. Подробный анализ может, таким образом, привести к неточным и ненадежным данным. Организации всегда должны остерегаться методов, подрывающих начинания.
111
ШШ^^ШШ
Роль топ-менеджмента
Какова роль топ-менеджмента в принятии решения о внедрении ERP? Во-первых, важно осознать, что только небольшое число руководителей организации может принимать решение, которое обойдется в среднем в 15 млн. долларов. Обычно такое решение в конечном итоге принимается СЕО компании, ее финансовым директором (chief financial officer, CFO), главным инженером (chief production officer, СРО) или советом директоров. Во-вторых, так как внедрение ERP системы сопровождается значительными изменениями в доминирующих процессах, инициатива перемен должна исходить от доминирующих сфер (например, от производственной или финансовой). Таким образом, топ-менеджмент этих доминирующих сфер или СЕО, или совет директоров должны быть задействованы в реальном решении. В-третьих, как заметил партнер, ответственный за SAP в фирме Andersen Consulting (см. Baatz 1996): «Проект по внедрению SAP изменит работу многих людей, и руководители, ответственные за И[ не могут в одиночку привносить такие изменения».
Таким образом, не удивительно, что, как сказал промышленный аналитик из Industry Directions: «В целом, компания SAP проигнорировала подразделения информационных систем. Вместо того чтобы продавать технологию, SAP направилась к экономическим покупателям [к СЕО и CFO] и убедила их в том, что это программное обеспечение изменит их бизнес» (Baatz 1996). SAP дала начало такому подходу, и другие производители ERP систем быстро последовали ее примеру в том, что может быть названо «маркетинговой гениальностью» (Baatz 1996).
Резюме
В данной главе были исследованы некоторые основания для принятия решения о внедрении ERP систем:
технологические основания («Проблема 2000-го года»),
конкурентные основания (чтобы остаться в бизнесе),
основания со стороны бизнес-процессов (вопросы эффективности и продуктивности),
стратегические основания (обслуживание клиентов и качество).
Первые две группы оснований обеспечивают ограниченную помощь в выборе процессов, необходимых для внедрения системы. Однако, если последние две группы оснований также ис-
пользуются, они могут быть использованы для определения формы реализации процессов и для оценки успешности, так как они детализируют процессы и делают возможным сравнительный анализ улучшений. В конечном итоге, чтобы получить общее признание, основания оцениваются в денежном и не в денежном выражении. Хотя фирмы действительно используют эти оценки, существует некоторое беспокойство относительно качества основных данных и того, когда их использовать. В любом случае, оценка успешности проекта требует сбора данных о расходах в течение всего жизненного цикла проекта.
Литература
Baatz, Е. (1996). «Marketing Genius». CIO Magazine, June 15.
Bailey, J. (1999). «Trash Haulers Are Taking Fancy Software to the Dump». Wall Street Journal, June 9.
Bashein, B.,Markus, L, and Finley, J. (1997). Safety Nets: Secrets of Effective Information Technology Controls. Morristown, NJ: Financial Executives Research Foundation.
Coteleer, M” Austin, R., and Nolan, R. (1998). «Cisco System, Inc.: Implementing ERP». Report no. 9-699-022, Harvard Business School, Cambridge, MA.
Shaft, W. (1997). «PeopleSoft lakes a Hit, But Watch for Comeback». Information Week, April 28.
Stevens, I (1998). «Proof Positive». Industry Week, August 17.
Vaughn, J. (1996). «Enterprise Applications». Software Magazine, May, pp. 67-70. Wagle, D.(1998). «The Case for ERP Systems». McKensey Quarterly, no. 2, pp. 130-8.
Приложение 7-1
Выбор ERP системы — собственная или готовая?
При принятии решения о внедрении ERR возможно, самым главным решением является решение вопроса о внедрении собственного ПО или ПО, разработанного сторонними фирмами. Существует два основных пути, в соответствии с которыми ERP могут быть реализованы сторонними фирмами. Во-первых, компания может провести анализ и решить, что она предпочтет работать с ERP системой, разработанной сторонней фирмой, вместо того, чтобы самостоятельно разрабатывать, внедрять и поддерживать систему. Во-вторых, все
подразделение обработки данных может использоваться по схеме аутсорсинга , и решение о внедрении ERP системы принимается в согласии с фирмой, которая предоставляет услуги такого ИТ-подразделения.
Использовать ERPf разработанную сторонней фирмой?
При выборе ERP системы, одним из важнейших вопросов является вопрос, должна ли быть система собственной или готовой? Компании Oracle (Stein 1998а), PeopleSoft (Stein 1998а), J.D. Edwards (Stein 1998b) и SAP (Sweat and Stein 1998) — все создают готовое ПО ERP.
Чтобы донести продукт до клиентов, при создании готового ПО необходимо сотрудничество с партнером. Например, SAP America сотрудничает с Andersen Consulting, /VT&T Customer Care и EDS (Sweat and Stein 1998). Компания J.D. Edwards сотрудничает c World Technology Services, IBM Global Services и другими.
Потенциальное преимущество готовых систем очевидно. Как сказал генеральный подрядчик (Stein 1998b), заключивший контракт на 60 млн. долларов с фирмой J.D. Edwards: «Нам был необходим пакет программ бухгалтерского учета, но мы не хотели совершать огромные инвестиции в программное обеспечение и оборудование. Заключив этот контракт, мы избежали огромных финансовых затрат и минимизировали потребность в администраторах информационных систем».
Однако есть и недостатки. Например, как заметил вице-президент по ИТ компании Fujitsu Microelectronics: «Ключевой проблемой является проблема соответствия нашего программного обеспечения бизнесу и оптимальности приложений для нашей компании. Я не уверен, что продукция независимых разработчиков решит эту проблему» (Stein 1998а).
Использование услуг подразделения обработки данных сторонней компании
В целом, вопрос, когда фирма должна начать работать по обработке данных со сторонними компаниями, не входит в круг проблем, затрагиваемых в данной книге. Однако нам важен вопрос, когда отдел обработки данных сторонней компании примет решение о внедрении ERP системы. Например, Херрера (Herrera 1999)
* То есть быть отдано «на откуп» сторонней организации (прим. науч, редактора).
сообщает, что компании IBM, принявшей на себя обязательства по обработке данных компании Kodak, придется принять такое решение.
Вопросы
Каковы достоинства и недостатки использования готовой ERP системы?
Каким фирмам подойдет использование готовой ERP системы?
Что приведет к внедрению ERP в фирмах (таких как Kodak), пользующихся услугами ИТ-подразделения сторонней компании?
Литература
Herrera, S. (1999). «Paradise Lost». Forbes Global, February 8.
Stein, T. (1998a). «PeopleSoft Ventures into the Unknown World of Outsourcing».
InfoWorld, January 19, p.35.
Stein, I (1998b). «J.D. Edwards Jumps into Outsourcing». Information Week Daily, February 12.
Sweat, J, and Stein, T.(1998). «SAP Formally Rolled Out a Program,...» Information Week Daily, February 24.
8
ВЫБОР ERP СИСТЕМЫ
В данной главе исследуется вопрос о том5 как фирмы осуществляют выбор среди различных ERP систем. Существуют два основных метода выбора ERP системы: анализ требований и анализ несоответствия. В данной「лаве объясняются эти два метода и исследуются достоинства и недостатки каждого из них, а также коротко рассказывается об альтернативном методе. Кроме то「о， здесь исследуются предположения, выходящие за рамки анализа требований и несоответствия, и некоторые ограничения этих двух методов. Рассматриваются также две компании, которые преодолели эти ограничения при проведенной ими оценке ERP систем, выйдя за рамки анализа требований и несоответствия. Наконец, в данной главе перечислены недостатки методов более широкой оценки.
Анализ требований
Анализ требований ——это обзор системных требований для организационных МОПов. В некоторых случаях требования сгруппированы в зависимости от их важности,——например, обязательные или факультативные, или расположены в определенном порядке (скажем) от 1 до 3. Требования отражены в документе о требованиях (в заявке на предложение ——request for proposal, RPF), который предоставляется различным производителям. Организация использует этот набор требований для того, чтобы судить о том, насколько различные части ПО соответствуют ее нуждам.
Сколько требований?
Документы с требованиями могут быть довольно большими. Например, одна компания (фирма А) с объемом продаж, оценивающимся в 40 млн. долларов, создала документ с 1 000 пунктами требований. Компания Timberjack с товарооборотом, оценивающимся в более чем 35 млн. долларов, предъявила 1 042 требования. Еще более крупная частная компания (фирма Б) в соответствующем документе также имела более 1 000 требований. Количество требований зависит от размера фирмы, определенных промышленных стандартов и от того, кто проводит анализ.
Время на проведение анализа
Из-за большого числа требований и процессов, охватываемых ERP системой, разработка документа с требованиями может потребовать значительного времени и средств. Фирма А смогла сделать полный анализ всего за месяц. Анализ, проведенный компанией Timberjack, потребовал трех месяцев. Фирме Б потребовалось четыре месяца на разработку данного документа.
Кто должен разрабатывать fразрабатывает) требования?
Кто разрабатывает эти требования? Обычно требования разрабатываются кем-то, кто хорошо знаком с существующим процессом; и ча-
сто тем, кто выполняет или будет выполнять работу, входящую в определенный набор требований. В некоторых случаях для создания моделей существующих процессов привлекаются менеджеры процессов.
Вопрос о том, кто должен разрабатывать требования, зависит от то「о, в чьем восприятии больше всего заинтересована фирма. Если используется текущий персонал, то требования будут отражать существующие процессы. Если ответственность несет менеджмент, требования тоже будут хорошо отражать реальность, так как менеджеры занимаются текущими операциями. Менеджеры могут предъявить требования о том, что, по их мнению, «здесь должно быть» или о том, что «здесь было» тогда, когда менеджер был ежедневно занят в процессе.
В фирмах А и Б текущие пользователи, задействованные в том или ином процессе, работали над требованиями вместе с консультантом. В компании Timberjack операции перемещали в пру「ой город. В процессе реализации проекта консультант работал с группой пользователей, задействованных в текущих процессах, которые, как предполагалось, не будут пользоваться новой системой. В Timberjack несомненно испытывали беспокойство о возможной потере знаний о текущих процессах.
При проведении анализа требований часто требуются консультанты ——и из-за их общих знаний об анализе требований, и из-за их стороннего взгляда на процессы. Возможно, самая лучшая команда ——это та, которая совмещает мнения менеджеров и работников, занятых в текущих процессах, с мнением консультанта, имеющего опыт и независимую точку зрения.
Рис. 8.1. Анализатор потребностей
Помощь в проведении анализа требований
Кроме консультантов существует ПО, которое находит различные требования в ПО конкурирующих производителей. Например, система Requirements Analyst («Анализатор потребностей») находит различные возможности разных пакетов бухгалтерского учета и модулей этих пакетов. Пользователи могут выбрать, какие возможности им необходимы, а затем произвести сравнения своих требований с возможностями ПО поставщика. Образец экрана показан на рисунке 8.1 (www.ctsguides.com).
Степень детализации (тонкость) требований
Требования значительно варьируются по степени своей детализации, которую также называют «тонкостью». Например, в некоторых случаях требование может относиться к набору лучших практик, в то время как в других случаях может быть определено единственное требование. Например, среди требований компании Timberjack были следующие:
возможность управления заказами в соответствии с методами лучших практик размещения заказов, контроля за их выполнением и экспедицией;
возможность осуществления электронного обмена данными с конкретными производителями;
возможность составления производственных программ поставщиков;
возможность отслеживания фактической даты доставки.
Преимущества анализа требований
Существуют несколько преимуществ анализа требований. Во- первых, в результате его проведения появляется перечень требований, которые можно использовать для сравнительного анализа различных пакетов ПО. При использовании анализа требований ПО может быть исследовано с целью обнаружения того, что фирма приобретает или теряет по сравнению с использованием традиционного ПО или альтернативной ERP системы. Во-вторых, анализ требований предоставляет основу для взаимодействия МОПов и их обсуждения. Соответственно, анализ может способствовать взаимодействию внутри подразделений и между ними. В-третьих, анализ требований часто приводит к лучшему пониманию ограничений существующих МОПов, что, в свою очередь, может помочь лучше осознать необходимость перемен. В-четвертых, анализ требований может быть использован для достижения решения о покупке новой системы, гаранти-
руя, что она соответствует определенным требованиям. Когда пользователи участвуют в процессе анализа, они осуществляют свой вклад в этот процесс и ——будем надеяться ——привносят ббльшую уверенность в правильности выбора системы. В-пятых, так как организация использует «обнаруженные» требования, она получает свидетельство того, что МОПы действительно работают как по отдельности, так и в целом.
Недостатки анализа требований
У анализа требований есть и некоторые недостатки. Во-первых, он может отнимать много времени, откладывая выбор системы. В описанных примерах потребовалось от одного до четырех месяцев на разработку документа с требованиями. Во-вторых, анализ требований может быть очень дорогим. Нередко такого рода анализ приводит к расходам на консалтинг; оценивающимся в 100 000 долларов или более, и это, не учитывая стоимости времени участников анализа от фирмы, для которой выполняется этот анализ. В-третьих, если документ с требованиями слишком большой и включает слишком много требований, производители ERP могут не ответить на них из-за своей занятости. В частности, единственными, кто ответит, могут быть производители, располагающие большим количеством времени (т. е. имеющие большее число незанятых людей). Если документ с требованиями слишком большой, фирмы ограничивают количество компаний, которые возможно ответят на них. В-четвертых, анализ требований может в конечном итоге определить требования, которые ограничат фирму устаревшими методами. Вместо этого для нее возможно более выгодным было бы подвергнуть существующие процессы реинжинирингу. В-пятых, процессы (и их взаимодействие) меняются, так что этот вид анализа включает требования, которые никогда не стабильны в полной мере. Анализ требований может предо- ставить в лучшем случае «снимок» процессов фирмы.
Формат требований
Анализ требований принимает, по крайней мере, две формы. Возможно, наиболее часто используемый подход ——это подготовка подробного списка всего того, что требуется от ПО. Этот список посылается поставщикам для того, чтобы они могли сравнить его с возможностями своего ПО.
Другой метод — это «сценарный» метод, который имеет один или иногда два этапа. Первый этап ——этап со свободным сценарием; на этом этапе клиенту показывают демонстрационные версии ERP
(разработанные их производителями). Клиент может управлять ими лишь в малой степени, но может попросить продемонстрировать конкретные характеристики, особенно важные для фирмы.
Обычно существует вторая стадия — стадия с определенным сценарием. При демонстрации производителя ERP просят использовать конкретные данные и выполнить конкретные операции. Например, если фирма заинтересована в возможностях проектного мониторинга, то производителя попросят создать проект на данном ПО. Этот метод особенно важен для определения несоответствий, которые потребуют модификации.
Анализ несоответствия:сравнение «как есть» и《как должно быть^
Альтернативный подход — проведение анализа «как есть» и анализа «как должно быть» и их последующее сравнение при помощи анализа несоответствия. Выражение «как есть» относится к работе имеющейся системы. Фирма должна впоследствии спланировать направление перехода от модели «как есть» к модели «как должно быть». Модель «как есть» обеспечивает сравнительный анализ возможностей имеющейся системы. Модель «как должно быть» может быть результатом реинжиниринга «с чистого листа» или реинжиниринга, «запускаемого технопо「ие济》* Если модель «как должно быть» разрабатывается независимо от какого-то определенного пакета про「рамм, то она является результатом реинжиниринга «с чистого листа». Если использован этот метод реинжиниринга, то модель «как должно быть» становится эквивалентной модели требований. Однако все чаще анализ «как должно быть» основывается на определенном ERP-пакете; в этом случае он «запускается технологией». Следовательно, анализ «как должно быть», базирующийся на готовом ПО, можно также назвать анализом «лучших практик».
Анализ несоответствия используется для сравнения результатов анализов «как есть» и «как должно быть» с целью определения того, какие несоответствия существуют между тем, что компания имеет на данный момент, и тем, что, как она решила, ей необходимо. В идеале клиенты могут использовать эту информацию при выборе ПО, наиболее соответствующего их нуждам. Как было сказано выше, выявление несоответствия позволяет фирме определить, какие модификации ПО могут потребоваться, чтобы оно соответствовало ее требованиям. В свою очередь определе-
ние этих модификаций может быть использовано для того, чтобы лучше определить расходы, не относящиеся к ПО, которые повлечет за собой конкретный выбор.
Однако существует много различных точек зрения на эти несоответствия и даже на то, что их создает. Например, что делать, имея списки то「о, что нужно фирме, и того, что предлагает поставщик? Должны ли мы просто сосчитать требования, чтобы понять, у ПО какого поставщика больше соответствий, и считать это ПО победителем? Не имея меры детализации, можем ли мы вообще «сосчитать» все это? Или мы должны принимать в расчет только самые важные требования? При анализе несоответствия эти вопросы адресованы конкретной фирме, делающей выбор. Однако некоторые начинают задаваться вопросом, нужно ли вообще проводить анализ несоответствия? Не следует ли использовать какой-то иной подход?
Возникающий подход
Консультанты все больше советуют фирмам не делать анализ «как есть». Вместо этого внедрение ERP рассматривается как истинный реинжиниринг; «запускаемый технопо「ией», который переходит сразу к процессу «как должно быть», используя определенный ERP пакет. Доводы приводятся следующие:
Каждый набор пакетов программ ERP соответствует организационным нуждам. Выбранная ERP система предположительно имеет примерно тот же набор лучших практик, что и любая другая, и все они примерно эквивалентны.
Копировать существующие процессы не имеет смысла. Организации не должны копировать существующие (устаревшие) процессы, а должны проводить реинжиниринг; используя возможности ERP системы. Соответственно, организации должны рассматривать внедрение ERP системы как возможность улучшить существующие у них процессы в свете новых технологий.
Априорный анализ лучших практик при внедрении ERP систем не должен иметь места. Вместо этого анализ лучших практик должен осуществляться только в контексте конкретной части ПО выбранной ERP системы.
Так как расходы на внедрение минимизированы путем привнесения в ПО лишь небольшого числа изменений, должны выбираться только лучшие практики, заложенные в ERP системе.
Как фактически выбирается ПО?
Вопрос, будет ли ПО в действительности соответствовать нуждам организации, остается открытым. Как результат, при данном подходе в процессе выбора используется дополнительная информация. Во-первых, есть ли похожие фирмы (или подразделения внутри фирмы), которые внедрили ERP систему? Если да, то какую систему они внедрили и насколько она соответствует их нуждам? Во- вторых, какое ПО рекомендовал консультант, которому вы доверяете? В некоторых случаях небольшое количество консультантов, которым вы доверяете, могут хорошо знать определенную ERP систему, которую они, возможно, рекомендуют. (Не удивительно, что мно「ие консультанты говорили мне, что это лучший из подходов.) В-третьих, если пакеты программ ERP имеют фактически одинаковые возможности, то это неплохая стратегия и для фирмы с относительно общими нуждами.
Однако в отношении некоторых процессов различные пакеты ERP имеют различающиеся характеристики (например, «доступно по обещанию», как в случае с компанией Quantum). В этом случае обнаружение ПО с уникальными характеристиками может стать очень важным фактором. С другой стороны, со временем может произойти сближение возможностей различных ERP систем, и будет все меньше и меньше различий между программными пакетами различных производителей.
Проблемы с анализом требованийи анализом несоответствия
Хотя анализ требований и анализ несоответствия имеют множество преимуществ, они делают некоторые важные неявные предположения и игнорируют ряд важных вопросов.
Предположение подразумеваемые обоими методами
Оба вида анализа делают некоторые важные предположения, которые должны быть исследованы любой фирмой, использующей их. Во-первых, оба подхода обычно предполагают, что предпочитаемый пакет про「рамм ERP — это тот, который соответствует большему количеству требований. К сожалению3 при этом игнорируются дру「ие точки зрения: возможно, акцент должен делаться не на всех характеристиках, а на модуле (модулях), которые наиболее важны для создания ценности.
Во-вторых, не принимается в расчет степень детализации, особенно когда организация перестает рассматривать степень удовлетворенности ее требований. Таким образом, при подсчетах, сравнивающих, сколько требований выполняется, элемент данных может быть приравнен по важности к целому процессу. В результате простой подсчет удовлетворяемых требований не предоставляет достаточного свидетельства в пользу выбора то「о или ино「о пакета программ.
Вопросы, игнорируемые обоими методами
Анализ требований и анализ несоответствия обычно акцентируют внимание на функциональных возможностях. В результате они обычно к!「норируют большое число факторов, включая следующие.
Стоимость. Анализ редко включает стоимость. Обычно анализ указывает на определенного поставщика или на нескольких поставщиков и только потом оценивается доступность по цене. Кажется, попытки анализа часто делаются без учета стоимости ПО. Однако отношение затраты/выгоды является одним из наиболее важных фактически в любой бизнес-ситуации. Игнорирование затрат может являться следствием того, кому поручена оценка. Если оценка выполняется на нижних уровнях организации, а бюджет контролируется на верхних, то эти два уровня, возможно, будет сложно свести воедино.
Время установки. В некоторых случаях организации могут столкнуться с ограниченностью во времени из-за своего желания догнать конкурентов или быть первыми среди внедривших систему. Зачастую такие вопросы, как время установки, не рассматриваются до тех пор, пока ПО не выбрано.
Гибкость, Понятием «гибкость» при его использовании в отношении ERP систем обычно обозначается способность использования множества лучших практик. Обычно, чем больше лучших практик доступно, тем ПО более гибкое.
Пользовательский интерфейс. Пользовательский интерфейс включает и ввод, и вывод данных. Естественно, что фирмы предпочитают более простые в использовании системы. Как мы уже「оворили, производители ERP все больше стараются сделать свои системы более легкими в использовании.
Способность к модернизации. Существуют, по крайней мере, два вопроса, касающиеся способности к модернизации: как часто выпускаются новые версии, и насколько легко провести модернизацию. Слишком частые или слишком редкие замены ПО на новые версии могут создать проблемы. Если модернизация проводится слиш-
ком часто, фирмы постоянно сталкиваются с необходимостью модернизации системы для получения новых возможностей и не знают, сколько же времени будут поддерживаться их более ранние версии. Если же модернизация проводится слишком редко, фирмы могут не получить тех функциональных возможностей, которые им нужны.
Вычислительная среда. Вычислительная среда или философия может быть важным вопросом. Как сообщалось, специализация компании Oracle на вычислительной среде «тонкого» клиента отрицательно повлияла на мнение некоторых экспертов о ее продукте. Вопрос о вычислительной среде может стоять не перед всеми фирмами, но в некоторых ERP система должна будет взаимодействовать с другими системами. В этом случае интерфейс может стать критически важным фактором выбора, который потребует дополнительной оценки.
Персонал по внедрению. Во мно「их проектах по внедрению ERP систем важную роль играют консультанты. Таким образом, квалификация и наличие такого персонала может повлиять на выбор ПО. Поэтому некоторые фирмы включают персонал по внедрению в анализ в качестве важной переменной.
Текущее использование и обслуживание. После внедрения ERP системы происходит переход к ежедневному использованию и обслуживанию. Обслуживание конкретных ERP систем может быть различным. Таким образом, этот набор факторов также необходимо включить в анализ. К сожалению, группа по выбору ERP системы может быть иной, чем группа внедрения, которая в свою очередь может быть иной, чем「руппа обслуживания. Следовательно, важность этого фактора интерпретируется по-разному.
Функциональные характеристики. Как будет рассказано в следующем параграфе, некоторые фирмы могут попытаться оценивать функциональность в качестве единственного фактора. В этом случае может возникнуть непонимание того, что составляет «функциональность», и это понятие будет варьироваться в зависимости от того, кто е「о употребляет.
Как организации оцениваюти выбирают программное обеспечение?
Попытки фирм использовать более широкий набор характеристик (помимо анализа требований и анализа несоответствия) мы будем называть «оценкой». Так как анализ требований и анализ несоот-
ветствия фокусируются только на функциях, а существует и множество дру「их вопросов, то встает вопрос, как же организации оценивают и выбирают ПО? В данном параграфе описывается подход, использованный компанией Timberjack (Romanow и др. 1998); пример использования дру「о「о метода дается в приложении.
Timbeijack
Компания Timberjack использовала несколько оценочных критериев и их удельный вес при выборе между системами QAD и Oracle Applications. Для разработки подхода к выбору между QAD и Oracle была выбрана небольшая группа людей (состоящая из четырех служащих компании и консультанта компании Coopers & Lybrand). Для сравнения систем QAD и Oracle эта「руппа решила использовать набор факторов, присвоив каждому некоторый вес, и выбрать систему с наибольшим общим весом. Факторы и их веса представлены в таблице 8.1.
Таблица 8.1. Оценочные факторы и их веса
Фактор
Вес
QAD
Oracle
Поддержка
20
Функциональность
30
Пользовательский интерфейс
10
Гибкость
20
Виды на будущее
10
Надежность
20
Интеграция
30
Платформа
20
ИТОГО
160
Некоторые моменты оценки,которые стоит принять во внимание
Оценка, выходящая за рамки анализа требований и анализа несоответствия, включает некоторые моменты, к которым нужно отнестись внимательно, в противном случае оценка будет необъективной.
Использование единственного числа
для оценки пакетов программ
Преимущество данного метода ——это то, что при его применении используется единственное число, которое можно просто приписать к каждой оцениваемой ERP системе. Однако, насколько разумно оценивать в числах такие аспекты, как «виды на будущее» и дру「ие фак-
торы? Кроме того, неразумно складывать числа таких различных ка- те「орий и предпопа「а]ъ при этом, что их сумма будет давать надежную оценку ERP системы.
Манипулирование факторами и их весами
К сожалению, выбранными факторами и соответствующими весами можно манипулировать. При наличии информации о двух или более ERP системах факторами и их весами можно манипулировать в пользу определенного пакета программ в ущерб другим. Например, компания Timberjack установила для функциональных возможностей вес, равный только 30 (из 160). Такой низкий вес говорит не в пользу систем с широкими функциональными возможностями, а именно на эти возможности делается основной акцент при осуществлении анализа требований и анализа несоответствия. Это показывает то, как факторами, используемыми в процессе оценки, можно манипулировать в пользу выбора определенной системы. Более то「о, факторов может быть слишком много или, наоборот, набор факторов может быть неполным. Например, компания Timberjack выбрала восемь факторов, среди которых не было таких, как, например, «персонал по внедрению» или «обслуживание».
В чем различия?
Чтобы сделать выбор между системами, нужно найти различия между ними. Как результат, фирмы могут найти то, что отличает системы друг от дру「а. Есть ли та единственная характеристика, которая может помочь сделать выбор? Такой пример мы видим с компанией Quantum, которая выбрала Oracle Applications из-за характеристики «доступно по обещанию». После того, как эти различия найдены, фирма может решить, какие среди них для нее важны.
Выбор против объяснения
Факторы и их веса — это инструмент либо для выбора ПО, либо для его объяснения, отчасти в зависимости от того, когда выбраны факторы и назначен вес. Если факторы и их веса выбраны до оценки ПО, они обеспечат базис для выбора, основанно「о на априорном понимании ПО и ор「анизации* Если факторы и их веса выбраны после оценки ПО, они могут дать толкование выбору с рациональной точки зрения.
Кто должен выбирать факторы и их веса?
Часто к проекту выбора привлекаются консультант или группа консультантов. Роль консультанта может заключаться в обес-
печении независимости выбора и предоставлении знаний о ERP системе. Однако консультанты тоже отличаются друг от друга, что оставляет возможность для манипуляций. Например, могут быть выбраны определенные консультанты из-за совпадения их мнений с мнением людей, осуществляющих выбор. Более того, теми, кто определяет или устанавливает веса, можно манипулировать или их можно «политизировать». Привлекая людей с определенными взглядами, можно склонить выбор ERP системы в ту или иную сторону.
Когда нужно выбирать факторы и их веса?
В некоторых случаях важность некоторых факторов нельзя определить, пока не известны возможности системы в целом. Более то「о, только изучая возможности системы и предпочтения организации, можно составить такие перечни. Перечни, составленные до исследования организации и ERP системы, могут не отражать полноту понимания, появляющуюся после исследования.
Факторы стоимости
На уровне бюджета фактор стоимости ПО является самым важным. В некоторых же случаях, как отмечалось ранее, стоимость игнорируют. Как фирмы принимают в расчет стоимость в процессе выбора? Одним из методов (использованным фирмой Б) было перечисление трех видов стоимости и использование при выборе их суммы (см. таблицу 8.2). (Фирма Б, в конечном ито「е, выбрала SAP).
Таблица 8.2. Стоимость ERP*
Существующая система
Oracle
SAP
Внедрение
3-5
4-8
6-10
Специальная настройка ПО
2-4
1-3
минимальна
Количество обслуживающего
персонала
15-20
10-15
8-10
Все цифры — в млн. долларов.
Хотя данный подход принимает во внимание экономические факторы, он к!「норирует преимущества. Например, он предполагает, что после специальной настройки каждая часть ПО обеспечит примерно эквивалентные преимущества. Кроме то「о, он не принимает
во внимание потенциальные преимущества, связанные с изменением бизнес-процессов с помощью ERP системы. Он также игнорирует стоимость обучения пользователей использованию новой системы (и, наоборот, преимущества отсутствия необходимости обучать пользователей в случае работы со старой системой).
Что характерно только для ERP?
Анализ требований, рассмотренный в данной главе, используется не только для ERP систем. Однако ERP системы предоставляют широкий набор лучших практик, и выбор ПО с учетом этих лучших практик характерен только в отношении ERR В то же время после ERP систем похожую стратегию выбора начали использовать и по отно- шениюкдру「им видам ПО. Кроме того, широкая база лучших практик делает ERP системы одним из уникальных программных продуктов, и некоторые консультанты уверенно рекомендуют их даже без проведения анализа требований.
Резюме
В данной главе мы рассмотрели то, как фирмы выбирают ERP системы. Обычно они выполняют либо анализ требований, либо анализ несоответствия. Однако и тот3 и дру「ой виды анализа имеют не только достоинства, но и недостатки. Например, анализ требований может скопировать устаревшие процессы, которые должны быть подвергнуты реинжинирингу. Отсутствие структурированного анализа несоответствия («как должно быть») внутри конкретной ERP системы может вызвать появление лучших практик, которые не могут быть реализованы, ПО систем планирования ресурсов предприятий имеет широкие, все более улучшающиеся возможности. Таким образом, альтернативной стратегией является выбор одно「о из лучших пакетов программ ERR с которым знаком консультант и который он где-то уже внедрил.
Анализ требований и анализ несоответствия рассматривают в первую очередь функциональные характеристики системы и, таким образом, игнорируют множество других факторов. В данной главе ма рассмотрели некоторые из этих упущенных проблем, а также исследовали методы, использованные двумя фирмами при выборе ERP систем.
Литература
Romanow, D,, Keil, М., and McFarlen, W, (1998). «Timberjack Parts: Packaged Software Selection Project». Report no. 9-398-085, Harvard Business School, Cambridge, MA.
Приложение 8-1
Chesapeake Display & Packaging
Chesapeake Display & Packaging — это дочерняя компания корпорации Chesapeake. Гэри Чеймис, вице-президент и СЮ компании, установил процесс выбора корпоративно「о ПО, состоящий из пяти шагов:
сформировать небольшую, тщательно подобранную команду;
связаться с поставщиками для организации демонстрации ПО;
попросить поставщика доказать е「о способность быстро внедрить систему;
проголосовать;
осуществить выбор.
Формирование небольшой, тщательно подобранной команды. Для выбора ПО была сформирована небольшая, тщательно подобранная команда. Людей отбирали в соответствии с их знанием бизнеса и бизнес-процессов. Люди имели различные взгляды; некоторые были узкоспециализированными специалистами, другие —— нет. В команду входили не более десяти человек.
Связаться с поставщиками для организации демонстрации ПО, Было выбрано ограниченное количество первоклассных производителей ПО для предприятий. С ними связались и попросили подготовить демонстрацию для команды выбора. Производители имели ограниченный доступ к членам команды до момента проведения демонстраций, которые было запланировано провести через три недели. Демонстрации должны были быть проведены за один-два дня. Поставщикам предоставлялась возможность самим выбрать оборудование и СУБД
Попросить поставщика доказать его способность быстро внедрить систему. Так как быстрое внедрение было одним из тре-
бований компании Chesapeake Display & Packaging (CDP), на демонстрации поставщиков попросили доказать их способности к внедрению. При этом были предъявлены следующие требования:
Таблица 83. Результаты голосования при выборе ПО в компании Chesapeake
Соответствие
Персонал
функциональности
по внедрению
Подразделение
Должность
BAAN JDE SSA
BAAN JDE SSA
Гэри Чеймис
CDP
вице-президент, СЮ
321
231
Элвис Брэннам
CDP
менеджер
по информационным
системам
231
321
Линда Виттер
CDP
поддержка продаж
321
321
Тед Сэмойтс
CDP
менеджер
по производству
231
231
Джек Керк
CDP
вице-президент, CFO
231
231
Джон Полгар
CDP
старший аналитик
231
231
Карл Уилкокс
CDP
администратор
по разработке
321
321
Ричард Гастингс
CDP
менеджер
по операциям
321
321
Мери Джин
Симмионс
СС
директор
по управлению
акциями
231
231
Дик Фасс
СС
аналитик
331
231
Ренди Грам
СС
внутренний аудитор
132
132
Билл Толи
СС
CFO
231
231
Дэвид Спенсер
СРС
технический
менеджер
231
231
Анна Уолш
СРС
менеджер
по информационным
системам
231
231
* CDP — Chesapeake Display & Packaging; CPC — Chesapeake Packaging Corporation; CC — Chesapeake Corporation.
голосующих попросили оценить каждую из опций ПО в диапазоне от 3 до 1 баллов, где 3 ——высший балл. Каждо「о члена команды попросили дать оценку, базируясь на своей сфере ответственности. Результаты 「олосования отражены в таблице 8.3.
Рекомендованное ПО. Из трех систем управления предприятием была выбрана система J.D. Edwards, так как в сумме она получила наибольшее количество баллов. Чеймис обозначил следующие характеристики, обеспечиваемые J.D. Edwards:
наилучшие финансовые характеристики;
единое интегрированное решение;
наличие модулей управления персоналом и расчета заработной платы;
продвинутый объектно-ориентированный набор инстру
ментов;
соответствующий потребностям продвинутый модуль планирования, позволяющий планировать на основе стоимости.
Вопросы
Как вы думаете, какую ERP систему выберет компания Chesapeake? Почему?
Каковы сильные и (возможно) слабые стороны метода выбора ПО, использованного компанией Chesapeake?
Приложение 8-2
Исследование, проведенное одним финансовым директором
Мы находимся на стадии оценки различных ERP систем. У нас есть краткий список различных поставщиков ПО, и, в конечном ито「е, мы решили получше взглянуть на SAR Вместе с консультантом (Coopers & Lybrand) мы разработали проект, состоящий из трех этапов:
анализ «как есть»；
анализ «как должно быть»;
процесс приведения в соответствие (соответствие двух видов анализа).
Мы пришли к выводу, что SAP не удовлетворяет нашим требованиям. В частности, модуль производства был далек от наших ожиданий и не дал нам той информации, которую мы сейчас имеем. Существует множество несоответствий между анализами «как есть» и «как
должно быть». Кроме того, SAP (из-за ее интегрированности) не настолько гибкая система, как та, которую мы используем сейчас.
В системе, используемой нами в данный момент, в реальном времени доступен о「ромннй объем информации. Кроме того, эта система была создана нашими работниками и является «ориентированной на потребителя». Возможности этой системы по использованию информации в реальном времени просто потрясающая, и это является ключевым фактором в наших отношениях с клиентами. К сожалению, модуль производства системы SAP не может идти ни в какое сравнение.
Так как есть несколько несоответствий, придется много программировать, если мы хотим получить то, что имеем в системе, используемой нами в данный момент. В результате мы попросили Coopers & Lybrand предоставить нам подробный отчет о стоимости проекта. Если нам придется покупать SAP только из-за финансовых модулей и модулей закупок, то система слишком дорогая.
У меня возникли следующие вопросы:
Стоит ли покупать интегрированную систему, в которой все же потребуется много программировать?
Не может ли проект стать слишком дорогим?
Решение, которое мы собираемся принять в скором времени, конечно, сложное. Есть ли какие-нибудь варианты? Буду рад получить советы.
9
ПРОЕКТИРОВАНИЕ ERP СИСТЕМ
Что нужно менять — бизнес-процессыили программное обеспечение ERP систем?
Выбирая ERP систему, фирмы сталкиваются с необходимостью принять решение о проекте с точки зрения «политики реинжиниринга», степени переделки ПО под нужды предприятия и нео6ходимо「о ор「анизационно「о реинжиниринга. С одной стороны, так как ни одно ПО не отвечает всем потребностям фирмы, некоторые фирмы приняли решение о значительной его переделке под свои процессы. Сдру- 「ой стороны, многие организации использовали внедрение нового ПО как шанс для изменения своих основных бизнес-процессов, проводя реинжиниринг в своей организации для приведения процессов в соответствие «лучшим практикам», содержащимся в ERP системе.
Для выяснения степени, в которой различные фирмы следуют различным подходам, исследовательская компания Forrester Research провела исследование (Lamonica 1998), выявившее следующие процентные показатели:
выбор приложений, соответствующих бизнесу, с небольшой переделкой — 37%;
переделка приложений для приведения их в соответствие с бизнесом — 5%;
проведение бизнес-реинжиниринга для соответствия приложению—41%;
отсутствие определенной политики ——17%.
В данной главе анализируются два основных вопроса.
Как политика реинжиниринга влияет на процесс выбора ПО?
Что нужно менять — бизнес-процессы или ПО ERP систем?
Как политика реинжиниринга влияет на процесс выбора ПО:к вопросу о важности моделирования «как есть»и «как должно быть»
Решение о модификации ПО или о реин*инирин「е бизнес-про- цессов (или того и другого) влияет на важность и использование моделирования «как есть» и «как должно быть». В результате решение о реинжиниринге нужно принимать вместе с решением о выборе ERP системы. Так как анализ «как есть» порождает модели существующих процессов, значимость такого анализа зависит от степени неизменности процессов. Так как анализ «как должно быть» порождает моде-
Запланированная степень изменения организационных процессов
Рис. 9.1. Когда необходим анализ «как есть»?
фнтнонфтнооо ФОХОЕ.С
фнтнонфтнооо ффзоаох
28оф^оас 2SB2^mH00B^0。匚 KsmHoiHOOO отноф^га^
ли процессов, которые организация будет внедрять (или внедрять вместо существующих процессов или дополнять существующие процессы), его важность зависит от степени изменений существующих процессов.
К вопросу。важности для ERP систем модели «как есть» фирмам, планирующим сохранить существующие процессы (и проводящим реинжиниринг в небольшом объеме или не проводящим его вообще), полезно проводить обширный анализ «как есть», чтобы убедиться, что ПО соответствует их нуждам. В такого рода ситуациях, чем лучше ПО подходит существующим процессам, тем лучше. Однако если фирма планирует обширный реинжиниринг процессов (как 40% фирм в исследовании организации Forrester Research), то модель «как есть» несколько теряет свою важность. Так как многие фирмы, внедряющие ERR планируют реинжиниринг своих процессов, нет большой необходимости разрабатывать классическую модель «как есть». Таким образом, фирмы все больше отказываются от проведения это вида анализа. См. рис. 9.1.
У использования модели «как есть» существуют потенциальные проблемы. Рассмотрим фирму, которая проводит анализ «как есть» и обнаруживает плохое соответствие существующих процессов ERP системе, которую она выбирает. Если запланирован минимальный реинжиниринг; то ор「анизация, возможно, упустила возможность выбора ПО, которое подходит ее процессам. Рассмотрим фирму, которая проводит анализ «как есть» и планирует обширный реинжиниринг этих существующих процессов. Выбор ERP системы, которая хорошо
Упущенная возможность выбора ПО, соответствующего нуждам
Возможность возвращения к существующим процессам
МинимальнаяВысокая
Запланированная степень изменения организационных процессов
Рис. 9.2. Потенциальные проблемы использования модели «как есть»
фхтнонфтёоо фнтнонфтнооо фохоё ффзоаох 2гаооф^оас 2нв2^тнофв^о 。匚 кнтйнфтнооо omHOOS^
соответствует существующим процессам, может ограничить возможность проведения обширного реин*инмрин「а. Если у фирмы возникают проблемы при внедрении новых процессов, то может возникнуть откат назад — от процессов, подвер「нутнх реинжинирингу, к версии с использованием существующих процессов. Эти два случая приведены на рис. 9.2.
К вопросу。важности моделей «как должно быть»
Если запланирована ограниченная модификация ПО, выбор процессов «как должно быть» обычно ограничивается теми процессами, которые доступны в ERP системе. В таком случае анализ «как должно быть» — это проблема выбора из набора процессов, доступных в ERP системе.
Однако если ПО должно быть значительно модифицировано, анализ «как должно быть» не является более проблемой выбора из набора процессов, а является проблемой разработки процессов. Анализ «как должно быть» становится больше похож на реинжини- рин「«с чистого листа» (а не на реинжиниринг «запускаемый технологией»), ограниченный только зависимостью от процессов, заложенных в ERP системе. Эта динамика показана на рис. 9.3.
Организационные изменения и изменения в ПО:реинжиниринг против Реинжиниринга
Наш анализ значимости моделей «как есть» и «как должно быть» принял два направления: степень изменения ор「анизационннх процессов и степень изменения ПО. Эти две переменные, определяющие степень необходимого реинжиниринга, являются основой даль- нейше「о сравнительного исследования.
Эйдан Вейн, который был менеджером проекта от SAP при внедрении корпорацией Microsoft системы SAP R/3 под управлением операционной системы Windows NT, назвал это внедрение «реинжинирингом с маленькой буквы с системой SAP R/3 в качестве агента изменений». Microsoft внедрила финансовые модули SAP, используя процессы, доступные в SAP R/3, без модификации ПО. Кроме то「о, так как Microsoft внедрила только финансовые модули, соответствие ее процессов возможностям системы было действительно хорошим. Если Microsoft провела реин- *инирин「«с маленькой буквы»5 то что же такое Реинжиниринг («с большой буквы»)?
2гаооф^оас ^SBQ^mHOOB^O。匚 HsmlQ一①кюomi① h>!2гаооф^оас ^SBQ^mHOOB^O。匚 HsmlQ一①кюomi① h>!Запланированная степень изменения организационных процессовРис. 9.3. Какая разноеидкостъ анализа «как должно бы.тъ>> необходима?Запланированная степень изменения организационных процессовРис. 9.3. Какая разноеидкостъ анализа «как должно бы.тъ>> необходима?osm&smHOOO фохоёosm&smHOOO фохоёфнтнонфтнооо ффзоаохфнтнонфтнооо ффзоаох
2гаооф^оас ^SBQ^mHOOB^O。匚 HsmlQ一①кюomi① h>!
2гаооф^оас ^SBQ^mHOOB^O。匚 HsmlQ一①кюomi① h>!
Запланированная степень изменения организационных процессов
Рис. 9.3. Какая разноеидкостъ анализа «как должно бы.тъ>> необходима?
Запланированная степень изменения организационных процессов
Рис. 9.3. Какая разноеидкостъ анализа «как должно бы.тъ>> необходима?
osm&smHOOO фохоё
osm&smHOOO фохоё
фнтнонфтнооо ффзоаох
фнтнонфтнооо ффзоаох
Реинжиниринг «с большой буквы» был бы всесторонней модификацией организационных процессов и ERP системы. При реинжиниринге «с маленькой буквы» организация внедряет ПО, которое хорошо соответствует ей; однако при реинжиниринге «с большой буквы» она меняет под свои нужды и процессы, и ПО. Эти два подхода изображены на рис. 9.4.
В следующих четырех параграфах рассматривается каждый квадрант изображенной на этом рисунке модели с описанием примеров, достоинств и недостатков, а также характеристик фирм, которые являются вероятными кандидатами на их внедрение.
тоооф^оасx-qHHOHtlEEHHRJdo ннн ①工①н п-ХФЕФбтоооф^оасx-qHHOHtlEEHHRJdo ннн ①工①н п-ХФЕФбминимальнаяминимальнаяВысокаяВысокаяСтепень изменения ПОРис. 9.4. Реинжиниринг «с маленькой буквы>> и «с большой буквы»Степень изменения ПОРис. 9.4. Реинжиниринг «с маленькой буквы>> и «с большой буквы»国0°方шKraxn-S2sxss国0°方шKraxn-S2sxss
тоооф^оасx-qHHOHtlEEHHRJdo ннн ①工①н п-ХФЕФб
тоооф^оасx-qHHOHtlEEHHRJdo ннн ①工①н п-ХФЕФб
минимальная
минимальная
Высокая
Высокая
Степень изменения ПО
Рис. 9.4. Реинжиниринг «с маленькой буквы>> и «с большой буквы»
Степень изменения ПО
Рис. 9.4. Реинжиниринг «с маленькой буквы>> и «с большой буквы»
国0°方шKraxn-S2sxss
国0°方шKraxn-S2sxss
Минимальные организационные измененияи изменения в ПО: реинжиниринг «с маленькой буквы»
Реин*инирин「«с маленькой буквы» осуществляется, когда фирма, внедряющая ERP систему, производит только минимальные изменения в данном ПО и минимальные изменения в конкретных бизнес-процессах организации при его внедрении. Для осуществления реинжиниринга «с маленькой буквы» ПО должно быть достаточно подходящим для внедрения в организации процессов, зафиксированных в системе, а организация должна иметь возможность адаптироваться к небольшим изменениям, необходимым, если ПО не совсем точно соответствует текущим процессам организации. При реинжиниринге «с маленькой буквы» существует высокая степень соответствия ПО текущим организационным процессам.
Пример
Классический пример реинжиниринга «с маленькой буквы» —— случай Microsoft. Корпорация внедрила систему SAP R/3, внеся в ПО минимальные изменения. ПО предоставило лучшие практики, приемлемые для Microsoft. В некоторых случаях принятие лучших практик, используемых в ПО, подразумевало изменения в организации. Однако в целом, очевидно, в бизнес-процессы и организацию было внесено совсем немного изменений.
Достоинства и недостатки
Реинжиниринг «с маленькой буквы» предоставляет преимущество более быстрого и более дешевого внедрения, так как нет необходимости менять ПО или процессы организации. Кроме то「。, так как дру「ие фирмы уже прошли похожей или той же дорогой, существует опыт, который может быть использован в прогнозировании времени и стоимости внедрения.
У реинжиниринга «с маленькой буквы» существуют, по крайней мере, два недостатка. Во-первых, так как процессы не меняются, количество людей также может не измениться. В результате, затраты на персонал могут быть не затронуты, возможно, вопреки ожиданиям. Во-вторых, даже проекты реинжиниринга «с маленькой буквы», в которых задействована ERP система, могут быть дорогостоящими. Следовательно, фирмы, проводившие такой реинжиниринг; возможно упустили высокие шансы изменить существующие процессы организации или адаптировать ПО для соответствия своим уникальным
требованиям. Так как крупные затраты на ПО случатся только через какое-то время, фирмы, проводившие реинжиниринг «с маленькой буквы», возможно, пропустили свое «окно возможностей».
Применимые процессы
Некоторые характерные процессы скорее будут подвергнуты реинжинирингу «с маленькой буквы», чем «с большой». Например, многие фирмы имеют схожие требования к финансовым процессам. Процессы, используемые для работы с кредиторской задолженностью в одной ор「анизации, очень мало отличаются от соответствующих процессов в дру「。济 организации при любом взгляде на реинжиниринг. Таким образом, стандартные и характерные процессы будут, вероятно, внедрениями с реинжинирингом «с маленькой буквы».
К тому же процессы1 для которых используется реинжиниринг «с маленькой буквы», вероятно, включают те, для которых использование уникальных процессов создает мало ценности. С другой стороны, финансовые и бэк-офисные процессы вряд ли будут рассматриваться как источник создания ценности, и поэтому могут подвергнуться только реинжинирингу «с маленькой буквы».
Потенциальные кандидаты на внедрение
Для определенных типов фирм существует большая вероятность использования реинжиниринга «с маленькой буквы». Это фирмы, внедряющие характерные (например, финансовые) процессы, или фирмы, которые не рассматривают информационные технологии как важный процесс, создающий ценность. Лучшие практики, встроенные в ERP системы, как правило, уже были использованы другими фирмами. Таким образом, фирмы, проводящие реинжиниринг «с маленькой буквы», вряд ли смогут разработать процессы, обеспечивающие какое-либо уникальное конкурентное преимущество. Так как внедренное ПО использует доступные процессы, большую часть внедрения можно копировать. Таким образом, никакое преимущество не будет поддержано.
Фирмы, проводящие при внедрении реин*инирин「《с маленькой буквы», будут скорее малыми или средними фирмами, которые «потребляют ПО». То есть, они по большей части используют ПО в том виде, в каком оно дается, и не имеют достаточно сил или ресурсов для того, чтобы заказать фирмам-производителям разработку специального ПО. Проводить внедрение с реинжинирингом «с маленькой буквы» могут и более крупные фирмы, которые (по той или иной
причине) не имеют терпения, ресурсов или заинтересованности в изменении ни своей организации, ни ПО. Например, в случае с Microsoft были разработаны два предыдущих проекта внедрения ERP систем модели клиент-сервер. На эти проекты были потрачены значительные ресурсы и время.
Интересы и отношения производителей ERPв данной области
Производители систем планирования ресурсов предприятий, такие как SAP, недвусмысленно выражают интерес к фирмам, внедряющим средства реинжиниринга «с маленькой буквы». Малым и средним предприятиям SAP обычно рекомендует не вносить изменения в ПО. Например, компания SAP разработала методику ASAR чтобы такие фирмы внедряли ее системы.
Значительные организационные измененияи минимальные изменения в ПО
Некоторые полагают, что одной из самых важных точек зрения на ERP системы является та, согласно которой ПО дает возможность и способствует изменению бизнеса. Например, как заметил Кевин Маккей, президент компании SAP America:
Пользователям SAP R/3 часто приходится менять свой бизнес для использования ПО, но стоимость и изменения стоят того, так как ПО позволяет компании работать более эффективно ... Это не проект внедрения [информационной технологии], а трансформация бизнеса. (Bailey 1999)
Хотя ERP предоставляет организациям «благоприятную возможность» изменить бизнес, некоторые фирмы из данного квадранта не видят необходимости менять процессы. Напротив, они рассматривают ее как принуждение при внедрении и ограничения ПО. Если бы ПО было разработано более полным и включало бы большее количество процессов, то мно「ие изменения организационных процессов были бы не сильно необходимы.
Примеры
Wall Street Journal (Bailey 1999) недавно написал о ситуации, сложившейся с группой фирм, занимающихся вывозом отходов, ко-
торые посчитали свое ПО SAP «ПО для свалки». Две лидирующие в данной области фирмы (Allied Waste и Waste Management) осуществляли внедрение SAP, но прекратили этот проект. Одну из основных причин указал Томас Ван Вилден, СЕО компании Allied Waste: «Они [SAP] ждут, что вы измените свой бизнес для того, чтобы работать с их программным обеспечением».
В этом квадранте проекты внедрения не всегда заканчиваются тем, что фирмы «выбрасывают на свалку» ПО SAR Например, как заметил Девид Эдмондсон, помощник проректора по информационным услугам Техасского христианского университета: «Мы переделали программное обеспечение совсем немного. Наш специалист-системотехник помогает нам менять наши бизнес-процессы. Лучше изменить их, чем модифицировать программное обеспечение» (Lamonica 1998).
Достоинства и недостатки
У изменения процессов, а не ПО, существуют некоторые преимущества. Во-первых, не внося изменения в ПО, фирмы облегчают процесс модернизации ERP с выпуском их последующих версий и релизов. Во-вторых, изменение ERP системы является сложной задачей. Модули интегрированы, и изменения в одном модуле могут потребовать изменений в других. В-третьих, изменение ПО означает, что фирме, вероятно, придется продолжать поддерживать изменения ПО, что потребует дополнительных расходов и сил, которые, в противном случае, могли бы не понадобиться. В-четвертых, ограничение процессов теми, что доступны в ERP системе, может дать фирмам возможность улучшить и стандартизировать их процессы.
Однако у изменения процессов с целью их приведения в соответствие с ПО могут быть и недостатки. Во-первых, процессы, создающие ценность, меняются на общеизвестные. Сообщалось, что ряд фирм вынуждены были изменить форму вознаграждения с системы начисления премиальных на обычную зарплату, чтобы процесс соответствовал ПО. К сожалению, такое фундаментальное изменение в процессах может привести к дисфункциональности поведения. Если процессы помогают создать ценность, то их изменение может привести к негативным последствиям для фирмы. Во-вторых, как было отмечено в предыдущем примере, изменения процессов организации могут не оказаться успешными. В этом случае, как видно на примере фирм, занятых вывозом отходов, организация утрачивала пользу от применения ПО.
Возможные и невероятные кандидаты на внедрение
Фирмы, внедряющие ERR расположенные в данном квадранте, ——это фирмы, которым легче изменить людей, чем ПО, или, по крайней мере, для них это более рентабельно. Консультант компании PricewaterhouseCoopers, специализирующийся на ERP системах, отметил: «Легче изменить людей, чем программное обеспечение ... Изменение менеджмента становится важным средством успешного изменения процессов».
Изменение бизнес-процессов может быть сложным в некоторых ситуациях. Например, если фирма сильно децентрализована (как в случае с фирмами, занятыми вывозом отходов), то изменение процессов может стать проблематичным, так как при наличии разных требований сложно выбрать (и внедрить) общие процессы в различных условиях.
Минимальные организационные измененияи значительные изменения в ПО
Вместо того чтобы менять организационные процессы, чтобы начать соответствовать ПО, некоторые фирмы могут решить изменить ПО под существующие процессы или внедрить другие лучшие практики, не доступные в ERP системе.
Примеры
Проектный менеджер компании Nestle заметил, что выбранные компанией процессы при внедрении SAP включали лучшие практики, не входившие в данное ПО. В частности, были выбраны некоторые из процессов и лучших практик, существующих в БД консультантов компании, что стимулировало изменения в ПО.
Приведем другой пример. Менеджер по обслуживанию SAP в Deere Company заметил: «Мы серьезно переделали программное обеспечение, так как у нас есть в этом большой опыт, и мы это делаем хорошо. Это сработало и удовлетворило потребности компании» (Lamonica 1998).
Достоинства и недостатки
Изменение ПО имеет ряд отрицательных сторон. Изменения делают сложными обслуживание и модернизацию ПО. Как сказал Стив Купер, директор корпоративных систем компании Corning:
Мы поняли трудность: если модифицировать программное обеспечение5 возникнут затраты. Затраты на начальную модификацию, на модернизацию и на поддержку программного обеспечения. (Lamonica 1998)
Переделка ПО под требования различных подразделений также может создать трудности его внедрения в других подразделениях. Хотя менеджер по обслуживанию SAP в компании Deere Company заметил, что переделка ПО в рамках проекта внедрения ERP прошла успешно, было также сказано: «То, что не работало, хорошо устанавливает стандарты и образцы, которые могут быть предъявлены другим подразделениям» (Lamonica 1998).
Вероятные кандидаты на внедрение
Процессы, создающие ценность, которые варьируются от компании к компании, являются потенциальным источником изменений ПО. Например, будут, вероятно, изменены модули управления производством или созданы соединения с традиционными системами.
Размер компании имеет большое влияние на ее способность измениться или изменить ПО. Более крупные компании имеют большие ресурсы, так что они могут легко изменить ПО. Как сказал СЮ компании Penwest Pharmaceuticals: «Большие компании мало подвижны, чтобы измениться для соответствия программному обеспечению» (Lamonica 1998).
Значительные организационные измененияи значительные изменения в ПО:реинжиниринг «с большой буквы»
Реинжиниринг «с большой буквы» проводится, конца организация осуществляет широкий круг изменений и в самой организации, и в ПО. В результате, чтобы осуществить реинжиниринг «с большой буквы», фирме необходимы значительные ресурсы и время.
Пример
Компания Boeing — пример компании, которая осуществила и широкие организационные изменения, и многочисленные изменения в ПО. Boeing исследовала все имеющиеся ERP и пришла к выводу, что ни один из программных пакетов не может удовлетворить ее специфические требования. Эти требования были настолько уникальными,
что компания BAAN пообещала работать с Boeing для того, чтобы создать подходящую версию. Однако Boeing сделала больше, чем просто изменила ПО (Crow 1998), — она также изменила собственные процессы для того, чтобы они отразили, например, новые концепции в «неприбыльном производстве».
Как сказал аналитик из AMR: «Размер и охват проекта действительно уникальны» (Busse 1998). Как и в 1998 匚 новая система компании Boeing объединяла 18 000 пользователей четырех географических регионов и 19 различных предприятий, причем планировалось увеличить число пользователей до 50 000 человек. Поддержка внедрения потребовала огромных ресурсов. Например, как заметил Басс (Busse 1998), компании Boeing приходилось обслуживать 374 традиционных приложения одновременно с новыми системами.
Каково же было вознаграждение? Как сказал один из консультантов компании Boeing: «До ... [новой системы] люди могли смотреть только вперед и назад, сейчас они могут смотреть также вверх и вниз» (Busse 1998). Кроме того, как заметил вице-президент компании: «Когда мы раньше запускали систему MRP (Material Requirements Planning ——материальное планирование), исчисление шло в днях. Тот же самый процесс сегодня занимает 37 минут».
Достоинства и недостатки
Существует, по крайней мере, два преимущества реинжиниринга «с большой буквы». Во-первых, в случае успешного внедрения фирма приобретает ПО и процессы, которые она хотела, обычно первой среди других. Во-вторых, в некоторых случаях (рассмотренных в следующем параграфе) партнер производителя ERP (в данном случае Boeing) принимает на себя некоторые затраты и риск при внедрении, становясь при этом тем самым «первым толкачом» системы.
Однако у реинжиниринга «с большой буквы» есть и ряд недостатков. Изменение ПО может быть очень дорогим начинанием. Например, как замечено в книге Lamonica (1998):
Компания Boeing увлеклась изменениями, их было несколько тысяч. Обслуживание стало настоящим кошмаром ——кончится тем, что нужно будет создавать еще одну организацию для поддержания программного обеспечения. Модернизация любого рода сложна, если вообще возможна.
Вместо того чтобы менять ПО, многие фирмы занимают такую позицию как Стив Купер, директор корпоративных систем компании Corning:
Что мы хотим, так это положиться в проведении для нас основ- но访 части модернизации на PeopleSoft. Если бы мы модифицировали программное обеспечение, это неблагоприятно отразилось бы на наше访 способности возложить обязанности по модернизации на PeopleSoft.
Из этих замечаний ясно, что фирмы, которые выберут стратегию реинжиниринга «с большой буквы», — это крупные фирмы с большим весом на рынке. Среди других кандидатов ——передовые фирмы, которые рассматриваются производителями ERP как те, благодаря кому они могут занять устойчивое положение в определенных отраслях.
Интересы и отношения производителей ERP
8 данной области
Продажа компанией BAAN ERP системы компании Boeing сделала BAAN одним из главных участников ERP-бизнеса. Поскольку BAAN добавила новые лучшие практики и изменила ПО так, как это было необходимо крупному производителю — подрядчику правительства, другие похожие фирмы (например, Litton Data Systems) тоже приобрели ПО BAAN.
С другой стороны, чем больше ERP система соответствует нуждам определенной фирмы, тем меньше возможность, что она будет соответствовать нуждам других компаний. Таким образом, внесение значительных изменений в ПО или конкретные лучшие практики может фактически ограничить продажи ERP систем другим фирмам. Некоторые даже утверждают, что в результате обслуживания фирмой BAAN компании Boeing она получила и систему, и имидж, не привлекательные для фирм, не имеющих отношения к данной отрасли.
Значительные изменения ПО:эволюция реинжиниринга «с большой буквы»в сторону реинжиниринга «с маленькой буквы»
В некоторых случаях значительных изменена访 в ПО фирма-производитель ERP системы эффективно сотрудничает с фирмой, осуществляющей внедрение, с целью расширения возможностей продукта и набора лучших практик. Соответственно, обширные изменения в ПО могут привести к появлению специфических версий ERP систем, разработанных для данной отрасли.
Специфические, разработанные для данной индустрии версии ПО иногда появляются в результате совместной работы с производителями ERP систем. В этих случаях разработчики ERP систем готовы принять на себя некоторые расходы на разработку ПО, чтобы другие организации могли получить доступ к этим процессам. Таким образом, происходит эволюция ERP систем: от ПО, которое может потребовать реинжиниринга «с большой буквы», к ПО, которому будет необходим только реинжиниринг «с маленькой буквы».
Примеры
Nash Finch
Согласно Стедману (Stedman 1998)，компания Nash Finch была первой, кто купил версию SAP, разработанную для розничной торговли*. Когда началось внедрение, необходимых функциональных возможностей для ведения розничной торговли не существовало, они создавались в рамках проекта. Как сказал директор по развитию систем компании Jo-Ann Stores: «Там, где функционал розничной торговли и производства системы SAP пересекаются, [SAP Retail] очень хороша. Но в сферах, специфичных для розничной торговли, глубины нет совсем».
Компания Nash Finch потратила 50 млн. долларов, прежде чем остановила проект в целях соответствия требованиям «Проблемы 2000-го года». Дело было не в финансовых модулях, а в других, специфичных для розничной торговли. В результате компания объявила, что внедрение продолжится после завершения проекта соответствия требованиям «Проблемы 2000-го года».
Внедрение компании Nash Finch — это проект реинжиниринга «с большой буквы». Имеющаяся на данный момент версия ПО не обеспечивает в полной мере внедрение лучших практик розничной торговли. Однако так как Nash Finch продолжает внедрение версии для розничной торговли, эти лучшие практики розничной торговли будут почерпнуты и вставлены в ПО. Постепенно, то, что начинается как внедрение с реинжинирингом «с большой буквы» для Nash Finch приведет к созданию ПО, которое может быть использовано другими фирмами для реинжиниринга «с маленькой буквы».
Boeing
Когда компания BAAN начала менять свое ПО для соответствия требованиям Boeing, другие компании оборонной промышленности
Система SAP Retail (прим, автора).
выразили к нему интерес. BAAN и Boeing вместе работали над расширением границ лучших практик. После того, как эти лучшие практики были включены в ПО, другие пользователи этих лучших практик выразили интерес к проведению того, что для них можно было бы назвать внедрением ПО с реинжинирингом «с маленькой буквы».
Провал внедрения и факторы успеха
Успешное внедрение ERP системы чаще всего возможно в тех случаях, конца существует лишь минимальная потребность в изменении бизнес-процессов и ПО. Это не значит, что все организации должны вносить в ПО лишь минимальные изменения, а только то, что существует большая возможность, что такое внедрение будет успешным.
Если большинство изменений касается организационных процессов (значительные изменения в процессах организации и минимальные изменения в ПО), то организационные недостатки внедрения, выбор не тех лучших практик или сопротивление изменениям (среди других факторов) могут привести к неудаче. С другой стороны, если большинство изменений касается ПО (минимальные изменения в процессах организации и значительные изменения в ПО), то одним из факторов неудачи является неспособность организации осуществлять большие ИТ-проекты. Наконец, если осуществляются большие изменения и в организационных процессах, и в ПО, то или/и те, или/и другие проблемы могут повлиять на возможность успеха. См. рис. 95
тоооф^оаЕXHHHOSrlBesHB.Jdo SXSSS ^ХФЕФНОтоооф^оаЕXHHHOSrlBesHB.Jdo SXSSS ^ХФЕФНОПотенциальный провал проекта из-за изменения процессовПотенциальный провал проекта из-за изменения процессов и технологических изменений ПОНаиболее высокая возможность успешного внедренияПотенциальный провал проекта из-за технологических изменений ПОПотенциальный провал проекта из-за изменения процессовПотенциальный провал проекта из-за изменения процессов и технологических изменений ПОНаиболее высокая возможность успешного внедренияПотенциальный провал проекта из-за технологических изменений ПОМинимальнаяВысокаяМинимальнаяВысокаяСтепень изменения ПОСтепень изменения ПО
тоооф^оаЕ
XHHHOSrlBesHB.Jdo SXSSS ^ХФЕФНО
тоооф^оаЕ
XHHHOSrlBesHB.Jdo SXSSS ^ХФЕФНО
Потенциальный провал проекта из-за изменения процессов
Потенциальный провал проекта из-за изменения процессов и технологических изменений ПО
Наиболее высокая возможность успешного внедрения
Потенциальный провал проекта из-за технологических изменений ПО
Потенциальный провал проекта из-за изменения процессов
Потенциальный провал проекта из-за изменения процессов и технологических изменений ПО
Наиболее высокая возможность успешного внедрения
Потенциальный провал проекта из-за технологических изменений ПО
МинимальнаяВысокая
МинимальнаяВысокая
Степень изменения ПО
Степень изменения ПО
Рис. 9.5
В целом, чтобы уменьшить возможность провала проекта фирмам потребуются затраты ресурсов и организационная адаптация в сфере (сферах), которые могут породить неудачу. На рисунке 9.5 показано, какие ресурсы и адаптация необходимы. Например, если изменения в организационных процессах минимальны, а изменения в ПО значительны, решающими станут проектный менеджмент в информационных технологиях. При противоположном сценарии, кода осуществляются значительные изменения в процессах организации и минимальные изменения в ПО, возникнет необходимость в серьезном «менеджменте изменений» для того, чтобы выбрать и внедрить подходящие процессы.
Какой квадрант? Какой метод?
Какой метод ——от реинжиниринга «с маленькой буквы» до реинжиниринга «с большой буквы» ——работает лучше, зависит от фирм, осуществляющих внедрение, их возможностей и ограничений и компромиссов, которых они хотят достичь. Фирма может выбрать реинжиниринг «с маленькой буквы» и успешно внедрить ПО, упуская, однако, возможность реинжиниринга бизнес-процессов. С другой стороны, фирма может выбрать реинжиниринг «с большой буквы», неся большие расходы и тратя много времени на внедрение, но зато станет первой в отрасли, кто установил ERP систему, и будет пользоваться соответствующими преимуществами. На протяжении всего времени возникает балансирование между расходами и результатами, зависящее от использованных критериев (а) выбора ERP системы и (б) общей оценки завершенности проекта.
Резюме
В данной главе представлен анализ вопроса: «Что нужно менять —бизнес-процессы или ПО ERP систем?» В процессе анализа мы исследовали важность двух видов моделирования: «как есть» и «как должно быть», и выяснили, например, что во многих случаях анализ «как есть» не нужен. Кроме того, в данной главе представлены понятия реинжиниринга «с маленькой буквы» и «с большой буквы». Мы исследовали те условия, в которых главным является изменение ПО, изменение организационных процессов,
не доминирует ни одно из изменений или подходят они оба. Как и в наших предыдущих обсуждениях, универсальных оптимальных решений не существует. Выбор подхода зависит от нескольких организационных переменных. Наконец, мы видели, что при использовании одной фирмой специфической для' данной отрасли информации, требующейся для реализации проекта реинжиниринга «с большой буквы», может возникнуть ситуация, когда другие фирмы впоследствии смогут проводить реинжиниринг «с маленькой буквы», используя то же самое ПО.
Литература
Bailey, J. (1999). «Trash Haulers Are Taking Fancy Software to the Dump». Wall Street Journal, June 9.
Busse,工(1998). «Boeing Takes Off with BAAN». InfoWorld, July 6.
Crow3 B. (1998). «Integration Lean Manufacturing Principles into BAAN ERP».
Unpublished presentation, April 23.
Lamonica, M. (1998). «Customizing ERP Falls from Favor». InfoWorld, November 23, pp, 1,57, 58.
Stedman, C. (1998). «Big Retail SAP Project Put on Ice». Computerworld, November 2, pp. 1, 104.
Приложение 9-1
Внедрение системы SAP корпорацией Microsoft
Клиенты и разработчики продукции Microsoft пользуются большей частью технологических ресурсов корпорации. Таким образом, администрация компании и ее внутренний менеджмент, включая финансовую группу, зачастую не получали необходимых им ИТ-ресурсов. Как сказал Скотт М. Боге, помощник корпоративного управляющего: «Что меня больше всего поразило, когда я пришел сюда,... так это то, что в области финансов Microsoft была не только не передовой компанией, а напоминала страну третьего мира» (Wallace 1995).
Microsoft
Корпорация Microsoft была основана как партнерство в 1975 г. и стала корпорацией в 1981 г., главный офис которой расположен в Редмонде, штат Вашингтон. Microsoft разрабатывает, производит, лицензирует, продает и поддерживает большое количество ПО, включая операционные системы (Windows), офисные системы (Word, Excel и т. а), инструментальные средства разработки, справочные средства (CD-ROM-энциклопедии) и другие продукты. Microsoft также продает книги, поддерживающие ее продукцию, доступную для широкого круга компьютеров, включая PC и Apple. Microsoft обеспечивает продуктами, работающими в среде клиент-сервер, и здесь продукция компании доминирует на рынке. Корпорация Microsoft занимается исследованиями и развитием своей продукции. Компания была очень успешной; она свободна от долговых обязательств и имеет в своем распоряжении большие объемы наличности. В середине 1996 匚 ее рыночная капитализация, превышающая рыночную капитализацию компаний Intel и IBM вместе взятых, оценивалась в сумму свыше 78 млрд, долларов.
ПО Microsoft для персональных компьютеров используется во всем мире. Большинство подрядчиков и служащих компании — эксперты в области вычислительной техники, которым требуется доступ к вычислительным ресурсам компании в любое время и из любого места. Во время проведения данного исследования корпорация Microsoft имела более 40 000 клиентов, более 3 000 серверов и более 20 Тбайт дисковой памяти в своем центре данных. Зная ее высокую квалификацию в сфере ИТ внутренние пользователи ИТ компании Microsoft ожидали, что все их ИТ-средства будут также легки в использовании, как коммерческие продукты Microsoft. Не стало сюрпризом, что в связи со своей высокой квалификацией и простотой пользования ПО служащие Microsoft нетерпеливы в отношении обучения использованию ПО.
Финансовая группаи финансовые системы корпорации Microsoft
Основной бизнес компании Microsoft — технологические инновации. Значит, решения принимаются, исходя из технологических и рыночных соображений, а не из сложных расчетов капиталовложений. Как заметил Боггс:
Главный риск для Microsoft — потерять возможности для инвес- тиим访 в новые технологии. В результате мы — не та компания, где главно访 <цвм*уще访 сило访 являются финансы. Мы не тратим много времени на проведение анализа движения «ценежно访 наличности перед приобретением ... Две движущие силы нашего бизнеса — это доход и фиксированные расходы (по больше访 части на людей).
Эти требования повлияли на роль и возможности финансовой группы. Финансовая группа говорит, что результаты ее деятельности —это «значимая, своевременная, качественная финансовая информация» и «соответствующие, поддерживающие, профессиональные услуги». Обязанности и умения финансовых специалистов компании Microsoft в области ИТ трудно отличить от их группы поддержки ИТ (information technology group, ITG). К. Д. Холман, директор группы информационных технологий, заметил:
Здесь все увлечены технопопие访.Например, некоторые из наших финансовых специалистов получили два образования (финансы и администрирование информационных систем или компьютерные науки). Обязанности в области финансов и ИТ постоянно переопределяются. На сега1aH只山нм访 день они очень нечеткие.
Традиционные системы компании Microsoft
Microsoft, как и многие другие крупные компании, поддерживала принятие решений в области управления и финансов, используя набор традиционных приложений, которые были созданы или куплены еще в век «мейнфреймовых» информационных технологий и переходный период. Компания рассматривала эти системы как преграду. Кроме того, культуре корпорации и ее процессам была глубоко присуща идея использования собственных продуктов.
В 1992 匚 внутренние системы управления информацией компании Microsoft было поддерживать очень дорого. «Проблема 2000-го года» являлась потенциальной проблемой для многих традиционных систем. Microsoft обладала десятками отдельных финансовых программ, каждая из которых имела специализированный интерфейс с общими финансовыми программами. Кроме того, традиционные системы Microsoft были интегрированы со специально спроектированными интерфейсами, обслуживание которых было сложной и дорогостоящей задачей. Интеграция традиционных систем требовала трудоемкого специального программирования. Изменения, привнесенные в любое из приложений или в любую из БД, потребовали бы до-
полнительных дорогостоящих изменений других систем. Обслуживание интерфейсов было примерно эквивалентным обслуживанию приложений и БД. Эйдан Вейн, руководитель проекта NT SAR сделал следующий комментарий:
По нашим подсчетам, ITG обслуживает более 400 приложений. А это большие системы. Чтобы вы поняли, насколько большие, скажу, что мы считаем МАС РАС [большой программный комплекс материального планирования] единым приложением. По кра访не访 мере, половину этих приложений может, в конечном итоге, заменить SAP.
Некоторые из пакетов программ, которые компания Microsoft приобрела, были настолько модифицированы, что их производители больше их не обслуживали. Кроме того, не были доступны некоторые важные финансовые возможности, и финансовые системы не удовлетворяли потребностей в своевременной финансовой информации. Более того, имевшиеся системы не смогли бы поддерживать проекты роста в будущем. Первое закрытие (бухгалтерских книг) в конце года заняло три недели, а каждое последующее закрытие в конце месяца занимало две недели. Компании необходимо было повысить скорость доступа менеджеров к информации.
Проблемы с процессами и объектами
Кроме проблем с традиционными системами у Microsoft существовали некоторые ограничения и проблемы с основными финансовыми процессами — в особенности, с закупками. Как объясняет Скотт Боге: «Мы были недостаточно практичными. Например, в закупках. Мы сидим на огромной куче денег и поэтому никогда не вели серьезных переговоров о скидках». Microsoft имеет очень свободную политику закупок, и почти все служащие совершают закупки на сумму до 1 000 долларов без предварительного одобрения (предварительное одобрение требовалось для покупок на сумму свыше 1 000 долларов и на юридически оформляемые контракты). В дополнение к такой свободной политике существовало не очень строгое следование процессам закупок. Как сказал Грег Хармон, руководитель проекта SAP: «В некоторых случаях мы только тогда узнавали о наших [финансовых и юридических] обязательствах, кода получали счета».
Проблемы были не только с процессом закупок.
Как сказал Хармон, компании Microsoft необходимо было повысить скорость выплат поставщикам.
Кроме того, по словам Вейна, «в области основных средств... Microsoft требуется от 75 до 90 дней на то, чтобы внести актив в бухгалтерские книги [например, компьютерное оборудование], конца он уже стоит на чьем-нибудь столе».
Также были проблемы с объектами системы, такими как списки поставщиков. Например, подконтрольные компании не имели общей схемы расчетов или списков поставщиков.
Решение о замене внутренних систем
В 1992 г. Microsoft начала рассматривать в качестве своих внутренних систем управления решения, работающие в среде клиент- сервер. ITG несла ответственность за внутренний менеджмент и административные системы компании. Она была централизованной и в то же время организованной в подгруппы по разработке приложений для различных групп внутренних потребителей.
ITG проводила политику использования, по возможности, готового ПО. Члены группы оценили три различные финансовые системы, работающие в среде клиент-сервер: Dun and Bradstreet (D&B), Platinum и SAR Было выбрано ПО D&B, находившееся в то время на стадии разработки. Microsoft начала установку программного пакета в рамках бэта-тестирования. Через 18 месяцев внедрение было приостановлено, так как ПО было недостаточно развитым, и отсутствовала бизнес-поддержка.
Между тем, компания SAP America стала лидирующим производителем ERP систем для работы в среде клиент-сервер в Соединенных Штатах, Система SAP R/3 все еще не имела всех функциональных возможностей системы R/2, базирующейся на мейнфрейме. Однако SAP была лидером рынка, и это означало то, что она, возможно, будет иметь стимулы и ресурсы для расширения своей деятельности в будущем.
В 1993 匸 ITG обнародовала план внедрения полного пакета программ SAR охватывающего всю компанию. Было запланировано внедрение финансового, операционного модулей и модуля управления персоналом. Этот проект продолжался около двух лет, пока Билл Гейтс не поставил вопрос о е「о бизнес-целях и его пользе.
По окончании проекта ITG была реорганизована. После реорганизации разработчики приложений были распределены между своими
внутренними потребителями, так что, например, финансовая группа имела собственную («финансовую») группу ИТ Кроме того, Джон Коннорс (вто время корпоративный управляющий) был назначен СЮ компании. Его обязанностью было улучшать процессы и снижать затраты. Кроме того, он должен был донести до сотрудников Microsoft понимание ценности внутренних инвестиций компании в ИТ
Выбор SAP
Решение исполнительных органов об установке SAP R/3 состоялось в 1994 г. Стив Баллмер (вице-президент по продажам и поддержке) посетил компанию Wal-Mart, которая прислала ему персональное приглашение. Wal-Mart была широко известна своими сложными информационными системами, и Баллмер был впечатлен ее достижениями.
Коннорс описал, какую реакцию вызвали у Баллмера системы Wal-Mart, и его указания финансовой группе Microsoft:
У нас был очень 门лохо访 процесс бюджетирования. ITG и финансовое подразделение разработали новую программу для бюджетирования, но она не работала... Дело было серьезно... Я только что вернулся из отпуска, а Стив Баллмер только что приехал из Wal-Mart. Стив постучался и открыл дверь моего кабинета. Я уже знал, что это был Стив, он всегда стучался по-особенному. Он вошел и сказал: «Вы издеваетесь [ненормативная лексика опущена]!» Я его понял. (Bashein, Markus, and Finley 1997)
Помощник корпоративного управляющего Скотт М. Боггс, руководивший бизнес-частью проекта, отметил: «Мы не оправдали проект с финансовой точки зрения. Он важен со стратегической точки зрения и поддерживался топ-менеджментом».
SAP и рамки проекта
Рамки проекта охватывали финансовые процессы от инициирования финансовых операций (например, закупок) до публикации финансовых результатов для внутреннего использования менеджерами и сотрудниками финансового отдела, а также для инвесторов. Для улучшения и запуска этого процесса финансовый отдел и подразде-
ление финансовых ИТ выбрали финансовые модули системы SAP R/3 (исключая приложения казначейства, налогообложения и аудита). SAP AG ——один из стратегических бизнес-партнеров Microsoft, а система SAP R/3 была лидирующим в Соединенных Штатах пакетом ПО для предприятий, базирующимся на модели клиент-сервер. Она могла работать со многими валютами — главный плюс, так как Microsoft имеет дочерние компании в 60 странах, — и имела «лучшие практики», встроенные в программный пакет. Кроме того, SAP и Microsoft выпустили на рынок совместный продукт — пакет технологий, состоящий из программы R/3, а также сетевой операционной системы Windows NT и СУБД SQL Server корпорации Microsoft.
Однако в 1995 г: большинство крупных компаний, выбравших систему SAP R/3, использовали операционную систему UNIX и СУБД Oracle. В то время не было примеров использования технологий SAP и Microsoft более чем 1 000 пользователями в распределенной системе. Грег Хармон дал следующую оценку: «Самая крупная установка NT [до нашей] в одном месте была та, в которой работали 650 человек; а в распределенной системе — 350 человек. И они работали только несколько дней». При использовании бэта-версии Windows NT 4.0 (поступившей в широкую продажу в августе 1996 г.) команда планировала провести установку сервера SAP/NT/SQL для оценки работы (неодновременной) 2 000 пользователей.
Проектная команда и график работы
По предложению Баллмера, Джон Коннорс отстаивал проект замены финансовых систем. Он назвал себя «самым убежденным сторонником проекта. Я убедил Билла и помощников президента компании». Коннорс описал ключевую роль, которую он играл в новом проекте следующим образом;
Я —не 门роектна访 менеджер. Я — не разработчик. Моя работа — устранять препятствия на пути к прогрессу. Это означает следующее. Во-первых, это значит донести до понимания ITG, что они должны быть частью команды. Я поступил правильно, назначив руководить бизнес-частью проекта человека из финансового отдела. В прошлом дело обстояло иначе. Во-вторых, это означает сказать: «Это то, что делаем мы... Нам не могут указывать, делать это или нет и как это делать». Я объездил с кратковременными визитами весь мир, чтобы донести это до всех. В-третьих, это означает получать поддержку от ру-
ководства — делать так, чтобы Баллмер или Билл уничтожали любое возникающее препятствие. В-четвертых, это означает говорить всем, как это важно для Microsoft, и работать слаженно, ццно访 коман- «цо访 с отделами маркетинга и продаж. В-пятых, это означает нанять очень хорошего проектного менеджера.
Коннорс назначил ответственным за весь проект Скотта Боггса. Боггс не занимался ИТ но он был важной фигурой в бизнес-процес- сах, напрямую связанных с проектом, он был «владельцем процессов». В Microsoft это еще называли быть «бизнес-лидером» — тем, кто выигрывает, если проект имеет успех, и проигрывает, если он терпит неудачу.
Боггс и Стив Линдеман (старший менеджер консолидаций) посетили конференцию 门опьзователе访 SAP, чтобы больше узнать о трудностях внедрения. Как заметил Линдеман:
Мне повезло, что я участвовал в проекте с самого начала. Бухгалтерии было бы проще возложить все это на отдел информационных услуг Мы со Скоттом пошли на ежегодную конференцию SAP в прошлом году, и там все компании говорили то же самое. [Не возла- 「а访те все на ИТ-подразделение.] Мы переглянулись и решили, что мы не допустим эту ошибку.
На конференции стало понятно, что система R/3 очень сложна. Было также очевидно, что при внедрении программного пакета полезно иметь людей с опытом его внедрения. В результате Коннорс нанял на должность проектного директора по внедрению SAP Грега Дж. Хармона из крупной консалтинговой фирмы. Эйдан Вейн из ITG был назначен проектным менеджером по внедрению NT SAR Эти проектные менеджеры сидели в одном помещении и делили обязанности по договоренности.
Лидеры проекта имели крайне напряженный график работы. Была поставлена задача завершить проект через девять месяцев. Бюджет был небольшим, но менеджерам разрешили использовать любой внутренний персонал, который им понадобится для реализации проекта. Проектные менеджеры сами провели собеседования и отобрали проектный персонал. Однако финансовая организация, имевшая небольшой персонал, не могла позволить себе заменить людей, выбранных для участия в проекте, и эти члены проектной команды должны были выполнять одновременно две штатные работы. В основном, эта схема работала, хотя, как заметил один из членов про-
ектной команды: «Во время завершения финансового цикла [в конце месяца] мы их часто теряли».
Члены проектной команды Microsoft также работали с несколькими группами консультантов и производителей. Как заметил Хармон:
Производители необходимы, но слишком полагаться на них не стоит... Компании, использующие консультантов для установки SAP, рискуют. С консультантами внедрение сначала идет быстро [потому что они уже обучены и знают этот пакет программ]. Но риск в том, что собственна访 персонал не обучен, чтобы проводить обслуживание пакета.
Чтобы внедрение шло быстро, и для обучения собственных сотрудников работе с пакетом программ, члены проектной команды Microsoft работали с консультантами и наняли людей со стороны, уже имевших опыт работы с SAR При внедрении SAP в Microsoft, в конечном счете, было задействовано примерно одинаковое число специалистов в финансовой области, служащих подразделения ИТ и внешних консультантов.
Реинжиниринг «с маленькой буквы»
Microsoft решила внедрить SAP без модификаций. Компания хотела воспользоваться преимуществами лучших практик, имевшихся в системе. Эйдан Вейн назвал этот подход «реинжинирингом с маленькой буквы с системой SAP R/3 в качестве движущей силы изменений». Вейн сказал:
Эта компания постоянно меняется. Можно даже сказать, что у нас хроническая болезнь неупорядоченности вследствие недостаточного внимания. Мы не можем позволить себе роскошь проведения тщательного инжиниринга процессов. Основной принцип нашего проекта — получить быстры访 результат и улучшить его по ходу работы. На все дается один год.
Так как Microsoft не переделывала SAP, можно было более точно определить время, требующееся на установку программного пакета. Однако, несмотря на решение не модифицировать SAR проект был обширным: нужно было установить 3 000 таблиц параметров, отражающих бизнес компании Microsoft. Хотя при реализации проекта ко-
личество отдельных финансовых приложений системы было значительно уменьшено (с 24 до 5), необходимы были интерфейсы для присоединения финансовых программ, не относящихся к системе SAP, к БД SAP.
Держаться принятого решения не переделывать SAP было трудно. Модель организации, используемая в SAR не совпадала с моделью, применяемой в Microsoft. Например, в SAP не используется термин «подразделение». Вместо этого в R/З применяются термины «центр прибыли» и «центр затрат» (каждый из которых обозначается кодом). Так как проектная команда не хотела модифицировать программу, при установке системы SAP все подразделения Microsoft пришлось определить или как «центры прибыли», или как «центры затрат».
Кроме того, SAP использует бизнес-модели, отличные от бизнес- моделей, используемых Microsoft. Например, SAP применяет концепцию «внутренних заказов» для операций внутри организации, которые присущи матричной бизнес-модели Microsoft. Однако Microsoft требовалось, чтобы внутренние заказы относились к подразделениям, продукции и проектам. Финансовый отдел хотел использовать три поля для классификации финансовых операций, но внутренние заказы в системе SAP имели только одно поле. Использование существующей бизнес-модели Microsoft потребовало бы модификации системы SAP. Альтернативный вариант подразумевал создание однозначных кодов для каждой из одно- двух- и трехсоставной комбинации бизнес-кате- горий ——комбинаторный кошмар, который фактически невозможно запомнить финансовому персоналу организационных единиц. Кроме того, коды внутренних заказов постоянно менялись бы. Далее, если бы таблицы кодов поддерживались в главном офисе, то персонал на местах мог бы столкнуться со значительными задержками доступа к операциям. Таким образом, чтобы схема с использованием единственного поля для описания внутренних заказов работала, проектной команде пришлось разрешить дочерним компаниям создавать при необходимости новые комбинации.
К сожалению, такие компромиссы при внедрении уменьшили стандартизацию, которую корпорация Microsoft пыталась ввести в свою структуру расчетов в мировом масштабе. Стив Линдеман сказал:
Это очень болезненное решение. Оно не давало мне спать ночью. То, как мы это сделали, было наименее плохим вариантом. Он соответствует потребностям бизнеса, но не является самым хорошим решением. Меня волновали люди, которым пришлось работать со всеми этими кодами. Следующая версия R/З предоставляет
большую гибкость в работе с внутренними заказами. Установим ли мы ее? Мы еще не внедрили имеющуюся. Это очень непростое решение. Замена была бы сложной.
Обучение
Несмотря на все усилия интегрировать свой персонал в процесс разработки, Microsoft пришлось значительно увеличить затраты на обучение. Система SAP R/3 потребовала значительного обучения. В итоге проектная команда по внедрению SAP перепланировала обучение и сделала его максимально кратким и быстрым. Новое обучение совмещало получение бизнес-знаний с развитием умений пользования SAP. Согласно Линдеману: «Я 20 раз проводил шестичасовой курс обучения вводу учетных данных в SAR Это был такой же курс обучения бухгалтерскому учету, как и обучения пользованию системными средствами».
Обучение пользованию SAP требовалось и для тех служащих, которые использовали SAPSET (стандартное отслеживание расходов). Microsoft пригрозила закрыть учетные записи тех, кто не обучается. Этот метод явно сработал. Как сказал Стив Линдеман: «Нам пришлось закрыть только около 20 счетов».
Внедрение
В августе 1996 г.——девять месяцев спустя после начала проекта —— установка SAP была завершена на 90%, затронув порядка с 1 000 фактических пользователей в главном офисе корпорации. Грег Хармон отметил: «Мы достигли всех намеченных целей. Это самый крупный проект в области информационных технологий, хорошо и в срок выполненный в компании Microsoft».
На создание первичного годового отчета с системой SAR похоже, понадобились те же три недели, что и при использовании традиционных систем. Однако Microsoft ожидала, что в будущем время, затрачиваемое на первичный годовой отчет, значительно сократится. Кроме того, ожидалось, что последующее составление ежемесячных отчетов может быть сокращено до двух-трех дней.
* То есть записи о пользователях информационной системы компании, обеспечивающей его доступ к системе (прим. науч, редактора).
Предполагалось, что из более 20 000 служащих компании Microsoft пользователями систем SAP по всему миру стали 2000 работников бухгалтерских и финансовых служб, занятых в продуктовых и функциональных подразделениях корпорации. Конечно, предполагалось, что и многие другие пользователи также будут использовать данные системы R/3.
Открытые вопросы
Хотя внедрение считалось успешным, существовали незакрытые вопросы, к которым проектная команда должна была еще обратиться.
Распространение s мировых масштабах
Начиная с августа 1996 г., и все последующие 12 месяцев Microsoft планировала распространить SAP среди своих дочерних компаний по всему миру. Планировалось, что большинство этих фирм фактически будут использовать ту же модель. Как сказал Вейн:
Никто не говорит, что SAP хуже, чем старая система. Дочерние компании испытывали довольно сильна访「опо/х в возможностях. И у них был год на установку SAP. Некоторые дочерние компании думают, что они могут сделать это лучше самостоятельно, что они вполне автономны. Но мы не предоставляем им ресурсов для значительных изменен/访.Microsoft довольно автократическая компания, когда дело доходит до отчетности перед центром, особенно в финансах. Мы предоставили им 33 таблицы, которые они могут конфигурировать [для отражения местных 门отребносте访 и различных 门уте访 ведения бизнеса]. Здесь [в главном офисе] мы конфигурируем 3 000 таблиц.
Кадры
Кадры ——следующая область, в которой будут заменяться традиционные приложения. Хотя СЮ Джон Коннорс говорит о себе, как о «большом стороннике SAP», он полагает, что приложение для управления кадрами в SAP недостаточно соответствует потребностям Microsoft. Кроме того, сотрудники департамента управления персоналом предпочитает модуль системы PeopleSoft соответствующему модулю SAP. Коннорс сказал: «На следующей неделе я собираюсь посетить SAPPHIRE [конференция пользователей SAP]. Я хочу узнать насчет того, что они собираются делать с модулем управления кадрами».
Отсутствие изменений s процессах закупок
Некоторые члены группы со стороны финансового отдела выразили озабоченность отсутствием изменений в санкционировании во внутреннем процессе закупок. Например, то, что любой служащий мог потратить до 1 000 долларов без санкционирования, осталось без изменений. В основном контроль осуществляли менеджеры, управляющие подконтрольными им ресурсами.「рб「Хармон объяснил, что риск был относительно небольшим: «70% наших операций оцениваются в сумму менее 1 000 долларов, но они составляют только 2% наших расходов. Если мы и ослабили контроль, то только контроль за расходами...»
В чем причина успеха?
Скотта Во「「оа часто просят дать совет по внедрению SAP. Он говорит, что отвечает следующим образом:
Я говорю с представителями многих других компаний о том, чем мы здесь занимаемся. Они всегда просят дать им совет. Во многих случаях я не знаю, что им сказать. Они, например, говорят: «У нас нет сети. Половина наших людей использует то, половина зто. СЕО не использует ИТ и не считает, что это важно. Что нам делать?» Я от* вечаю им: «Я не знаю. У меня таких проблем нет».
Литература
Wallace, R (1995). «Microsoft's Finance Department Gets Up to Speed». InfoWorld, June 5, p.58.
Вопросы
Каков риск для Microsoft в данном начинании?
Почему не были успешными первые два внедрения ERP системы?
Насколько важно задействовать бизнес-сферы в ERP системах?
Объясните понятие реинжиниринг «с маленькой буквы». Что будет называться реинжинирингом «с большой буквы»?
Обдумайте компромиссы при внедрении. Было ли их слишком много? Почему да/нет?
Было ли начинание успешным? Почему да/нет?
Должна ли корпорация Microsoft внедрять модуль управления кадрами SAP? Почему да/нет?
10 ПРОЕКТИРОВАНИЕ ERP СИСТЕМ
Выбор стандартных моделей, объектов и процессов
Одним из критически важных решений, которые нужно принять в отношении любой ERP системы, это выбор общих стандартных МОПов, т. е. моделей (например, моделей организации), объектов (например, планы и списки поставщиков) и процессов (например, управление заказами). Выражения «общие ... и глобальные» и «реализуемые многими» стали рассматриваться в некоторых компаниях как определяющие для помощи при внедрении этих общих МОПов (см. СЮ 1996). Вместо того чтобы, учитывая предшествующую деятельность каждой организационной единицы, выбирать для нее свои собственные МОПы, как это часто делается в традиционных системах, компания, имеющая ERP систему, будет использовать одни и те же МОПы для каждой организационной единицы. Однако выбор, внедрение и использование общих МОПов ——задача непростая. Из-за этих МОПов в фирме возникнут противоречия. Поэтому в данной главе мы обращаемся к следующим вопросам.
Почему МОПы важны?
Откуда берутся общие МОПы?
Почему фирмам необходимы общие МОПы для ERP систем?
Почему фирмы не имели общих МОПов до ERP систем?
Почему трудно выбрать общие стандарты?
Каковы некоторые мотивы выбора?
Какие методы были использованы для выбора общих ERP МОПов, чтобы разработать такие «общие... и глобальные» процессы, чтобы их «реализовывали многие»?
Почему МОПы важны?
Качество МОПов будет оказывать о「ромноб влияние на общий успех внедрения ERP системы. МОПы, не эффективные для конкретной фирмы, могут нарушить всю ее деятельность. С дру「о〃 стороны, МОПы, отвечающие нуждам фирмы, мо「утулучи!ить ее функционирование и обеспечить ей конкурентное преимущество. Таким образом, процесс, который фирма использует при выборе МОПов, имеет важное значение.
Откуда берутся общие МОПы?
Откуда берутся стандартные объекты и процессы? В данном параграфе кратко изложены интервью с двумя крупными фирмами относительно источника их общих МОПов.
Из беседы с ERP проект-менеджером компании Nestle (Соединенные Штаты) стало известно, как эта фирма выбирала варианты бизнес-процессов при внедрении SAP. Во-первых, она решила, что во всех трех ее отделениях в США будут внедрены общие МОПы. Во-вторых, «кандидатами», которые должны были подвбр「нуться оценке, стали МОПы, существующие в каждом из трех отделений. В-третьих, для формирования МОП- кандидате в были использованы БД лучших практик, предоставленные как системой SAP, так и привлеченные консультантом. В некоторых случаях были разработаны смешанные МОПы, информация для создания которых бралась из разных источников. В-четвертых, команда, состоявшая из специалистов разных функциональных подразделений, использовала оба этих набора МОПов для выбора стандартных объектов и бизнес-процессов компании.
Из беседы с заместителем ERP проект-менеджера компании Litton Data Systems выяснилось, что такой же метод был использован этой компанией для создания набора стандартов при внедрении системы BAAN, но источник стандартов был несколько иным из-за специфических требований производства. Как и в компании Nestle, для создания и оценки вариантов выбора была создана группа, состоявшая из специалистов разных функциональных подразделений. Однако, поскольку компания Litton Data Systems участвует в нескольких проектах для фбдбрально「。правительства (в дополнение к дру「弘м источникам), ей были необходимы также специфические «федеральные» МОПы, которые соответствовали бы определенным нормативным документам (например, требования отчетности для государственных контрактов).
Почему до использования ERP систем у фирмне было общих МОПов?
Почему ERP системам требуются общие МОПы, и почему фирмы не мели общих МОПов до использования ERP систем? Ответ на этот вопрос можно дать, рассмотрев несколько факторов, среди которых технология, использование различий на местах и управление подразделениями. Изначально большая часть ПО была разработана на заказ,
и оно носило локальный характер. Технологические о「ранк14бнк!я приводили к тому, что подразделения могли выбирать различное оборудование и, значит, (зависящее от него) различное ПО. В результате конкретные подразделения и предприятия использовали при выборе ПО и МОПов уникальные характеристики, соответствующие их локальным требованиям. Например, объекты (списки поставщиков, продукции, покупателей, таблицы счетов) выбирались и разрабатывались с учетом локальных процессов и потребностей в принятии решений.
Несовместимые ПО и МОПы усложняли интеграцию множества подразделений. Следовательно, становилось все труднее координировать их деятельность для удовлетворения все возрастающих тре- бованк!访 со стороны клиентов и конкуренции. Однако постепенно становились доступными клиент-серверные и сетевые технологии, а также соответствующее ПО, что позволяло выбирать общее ПО ERP систем в качестве решения для предприятия.
Почему фирмам необходимы общие МОПы для ERP систем?
В отличие от локального ПО, созданного на заказ, ERP системы — это готовое («коробочное») ПО, спроектированное и разработанное для внедрения во многих компаниях и, 6олббто「о, для интеграции всех подразделений и предприятий компании, для создания общего для всей корпорации представления данных. Как заметил Браунли (Brownlee 1996, с. R18): «Когда служащие компании Colgate входят в сеть, у них на экране появляются одни и те же опции, неважно, находятся они в Кембридже, Берлингтоне или Нью-Йорке».
Таким образом, ERP системы обеспечивают общими МОПами. Но почему фирмы нуждаются во внедрении общих МОПов при внедрении ERP систем? В данном параграфе рассмотрены некоторые причины, собранные из различных примеров внедрения ERP:
требования со стороны ПО;
повышение уровня обслуживания клиентов;
восстановление управления процессами;
необходимость。6山б「。представления данных в организации;
получение прибыли и сокращение расходов.
Требования со стороны ПО
Возможно самой непосредственной причиной внедрения стандартных ERP объектов и процессов является то, что зто「о требует ПО этих систем. Как сказал вице-президент компании Red Pepper
Software: «Не важно производит предприятие сталь, каучук или электронику ——SAP несет с собой общий набор параметров, который управляет конкретными предприятиями» (Vaughn 1996, с. 72). Стандартные списки продукции и стандартные прайс-листы были необходимы и при внедрении SAP компанией Owens Corning, которая
традиционно функционировала как「руппа автономных предприятий. «Каждое предприятие имело собственную товарную специализацию», 一 говорит Доменико Сесере, президент кровельного и асфальтного предприятий. Каждое предприятие также имело собственные прайс-листы, созданные за годы заключения конкретных сделок с клиентами... Однако SAP R/3 потребовала, чтобы персонал мистера Сесере использовал единый список продукции и единый прайс-лист. (White, Clark, and Ascarelli 1997; выделено мной)
Повышение уровня обслуживания клиентов
ПО планирования ресурсов предприятий позволяет интегрировать многочисленные подразделения и заводы в рамках предприятия, гарантируя, что все пользователи будут иметь доступ к одной и той же ин - формации. Это улучшает уровень обслуживания клиентов в соответствии с их потребностями. Компания Owens Corning решила внедрить систему SAP R/3 для достижения единого представления данных в компании и для оперативного обслуживания клиентов (White и др. 1997).
До настоящего момента клиенты звонили на кровельное предприятие компании Owens Corning для получения партии кровельной дранки, делали отдельный звонок чтобы заказать наружную обшивку, и еще один звонок, чтобы заказать широко известный изоляционный материал, производимый компанией.
Новый подход компании был следующим: она должна предложить сделать всего один звонок для приобретения всей необходимой строителям наружной обшивки, изоляции, труб и кровельного материала. SAP R/3 предоставит компании Owens Corning эту возможность, позволяя персоналу отдела продаж увидеть, что доступно на любом предприятии или складе, и быстро собрать заказы для клиентов.
Восстановление управления процессами
В некоторых случаях различные территориально распределенные подразделения организации используют процессы, кото-
рые производят впечатление вышедших из-под контроля. Фирмы, как видно на примере компании Vandelay, внедряют ERP системы, чтобы восстановить контроль над этими процессами и чтобы ор「ан^заи^я внедрила лучшие практики (McAfee and Upton 1996, с.4-5):
Практика выполнения операций географически разделенными подразделениями компании Vandelay была так же разнообразна, как и используемые ею информационные системы. Не было единообразных, признанных «лучшими» методов выписывания счетов клиентам, закрытия счетов в конце месяца, резервирования запасов на складе под заказ клиента или выполнения сотни других действий произ8одст8енно「о процесса, которые требовали использования компьютера или ввода данных.
Для решения... проблем, связанных с системами и установленными порядками, компания Vandelay решила купить и установить единственную ERP систему, которая объединила бы функции 8се「о, ранее разрозненно「о ПО. Компания также собиралась стандартизовать деятельность географически разделенных подразделений.
Общее представление данных
Некоторые фирмы пытаются произвести внедрение ERP системы при наличии у каждой организационной единицы собственных объектов. Однако большинство фирм, выбирающих ERP, хотят избежать негативных последствий использования различных и фра「мен・ тарных МОПов.
Чтобы создать общее представление данных, необходим набор общих организационных объектов (например, списки поставщиков и клиентов). Эти объекты дают возможность сбора информации в различных условиях и сохранения при этом общего представления информации. Например, как сказал Вон (Vaughn 1996, с. 74):
Компании Elf Atochem North America Inc. в Филадельфии переводят на работу с системой SAP 13 организационных единиц... Корпорация пришла к этому решению, так как ее различные компании были реорганизованы для того, чтобы начать работать как единая компания. В результате эта компания унаследовала «много различных компьютерных систем и путей ведения бизнеса». Общее представление разнообразных данных было важно...
Получение прибыли и сокращение расходов
Внедрение стандартных объектов и процессов может принести прибыль и сократить расходы. Например, как сказал руководитель IT- подразделения компании Pirelli Ар弘「о Андреони: «Чем больше стандартизации, тем лб「нб реализовывать новые идеи и реа「弘ровать на новые возможности» (Wakin 1998, с. 48). Андреони также отметил, что стандартизация может уменьшить расходы. Например, до стандартизации компания Pirelli имела универсальные вспомо「атбльныб офисы и созданное на заказ ПО в каждой из пяти стран. ПО планирования ресурсов предприятий было использовано для замены персонала многочисленных бэк-офисов персоналом единственного бэк- офиса в Швейцарии с сокращением расходов на 25%. В настоящий момент офисы в каждой из стран отсылают данные центральным серверам компании.
Почему трудно выбрать общие стандарты?
Так как ERP системы разработаны для предприятия, их внедрение требует принятия множества решений, включая выбор стандартных объектов и процессов, которые будут использоваться. Например, в случае с компанией Vandelay (McAfee and Upton 1996) для облегчения взаимодействия и координирования различных ор「анмза・ ционных единиц, таких как фабрики и подразделения были внедрены некоторые стандарты, включая общую таблицу счетов, общие номера поставщиков и общие номера компонентов. Однако некоторые МО- Пы приносят неодинаковую пользу определенным организационным единицам. То, что принимается для всеоб山б「о использования, не всегда является самым лучшим или предпочтительным на местах, в каждом подразделении. Например, Вон (Vaughn 1996, с. 72), цитируя Криса Руна, вице-президента компании Red Pepper Software, сказал: «Стандартные объекты ERP системы полезны, если пользователи финансовых данных хотят консолидировать информацию множества организационных единиц, но... для конкретных подразделений общее представление данных может быть неоптимальным». Стандартизация процессов и объектов ERP системой приводит к общим положительным результатам, но некоторые из них появляются за счет потерь местных специфических возможностей.
Более того, из-за разницы для корпорации и подразделений в выгодах, создаваемых выбранными стандартными объектами и процессами, 「рупповоб принятие решений может стать политическим
процессом, который вызовет стратегически осмысленное поведение для продвижения интересов каждой фракции. В результате различия между общими интересами и интересами подразделений могут, в конечном 弘丁。「6, привести к конфликтам. Выбор стандартных объектов и процессов также не всегда способствуют общей пользе корпорации, особенно когда некоторые подразделения получают больше выгод, чем другие.
Списки продукции: общий стандартный объект
Рассмотрим в качестве общего стандартного объекта список продукции. Список продукции присваивает уникальный идентификатор каждому продукту с целью ввода и вывода данных об этом продукте. Если общий список продукции принимается во всех подразделениях, это означает, что каждое из них использует один и тот же список продукции, который обычно обеспечивает достаточную「弘бкость для добавления новых продуктов в дополнение к существующим. Однако информационные нужды не обязательно одинаковы для всех подразделений компании, так как подразделения имеют различную продукцию и рынки. Некоторые виды продукции могут использоваться только в одном подразделении; некоторые подразделения могут нуждаться в более всесторонних и подробных списках продукции, чем дру「弘6, и т. д.
Таким образом, различные бизнес-подразделения и единицы несут неодинаковые затраты при внедрении стандартного списка продукции в зависимости от того, чей список был выбран. Если бы список продукции определенного подразделения использовался как общий стандарт компании, этому подразделению, естественно, потребовалось лишь минимальное обучение персонала, и оно испытало бы минимальные трудности при внедрении. Кроме то「о, такой список больше соответствовал бы интересам этого подразделения в отношении, например, добавления новых продуктов. Однако для дру- 「их подразделений этот список был бы совершенно новым, потребовалось бы серьезное обучение, и он мог бы не соответствовать их нуждам.
Подразделения обычно приходят к выводу, что общий список продукции —— не настолько эффективный, как их предыдущий список. Например, изделия из списка продукции, закодированные при помощи вдвое большего количества цифр, могут занять вдвое больше времени при вводе. При этом вероятность ошибок при вводе данных более высока, а, значит; качество информации
может снизиться.
Насколько отличаются стандарты подразделений от корпоративных стандартов?
Какой процент МОПов допустим для формирования подразделениями? Цифра, возможно варьируется от организации к организации. Однако, как было замечено при обсуждении компании Owens Corning (CIO 1996), всегда есть исключения из правила «общие ... и глобальные»: «С SAP всегда будут вариации в процессах на уровне организационных единиц, особенно касающиеся клиентов... Моя работа ——гарантировать, чтобы эти вариации были скорее исключением, чем правилом». При внедрении системы компанией Microsoft головной офис сформировал 3 000 таблиц, в то время как локальным офисам разрешили формировать примерно 30 таблиц (Bashein, Markus, and Finley 1997).
Насколько серьезно подразделения
и корпорация осуществляют процесс выбора?
Выбор общих МОПов — это серьезное дело для всех его участников. В некоторых случаях процесс выбора может стать очень эмоциональным. Например, в случае внедрения системы компанией Owens Corning (White и др. 1997) возник серьезный конфликт из-за объекта:
Однако SAP R/3 потребовала, чтобы персонал Сесере использовал единственный список продукции и единственный прайс-лист. Персонал сначала сопротивлялся передаче контроля над установлением цен и маркетингом центральной команде, располагающей компьютерами. «Моя команда готова была [меня] убить, если бы мы им уступили»,——сказал он.
Таким образом, для фирм может быть важно попробовать выбрать МОП ы, используя систематический подход.
Что побуждает к выбору?
Комитеты по планированию ресурсов предприятий обычно включают представителей из каадого подразделения, интересы которого затронуты, чтобы они могли высказать свои предпочтения относительно внедряемых стандартов. Предпочтения, сделанные подразделениями, могут иметь причины, описанные ниже.
Максимизация корпоративной пользы. В идеале каждое подразделение отложит в сторону свои личные цели и будет работать
на разработку стандартов, которые максимизируют глобальную корпоративную пользу. В реальности же подразделения принимали решения, исходя из своих интересов.
Минимизация затрат подразделения на изменения. Вместо того, чтобы максимизировать корпоративную пользу, подразделение может работать на сохранение своих собственных объектов или процессов для того, чтобы минимизировать затраты на изменения, такие как обучение имеющегося персонала или найм нового для использования (или внедрения) новых стандартов. Подразделение, не добившееся продвижения своих собственных стандартов в качестве корпоративных, может все же минимизировать свои затраты на изменения, выбрав стандарт, наиболее близкий к собственному.
Реагирование на конкуренцию. Глобальная конкуренция вынудила многие компании начать пользоваться услугами сторонних организаций взамен услуг; ранее предоставляемых собственными подразделениями. Поэтому подразделение, столкнувшееся с потенциальной угрозой ликвидации, может отрба「ировать на нее осуществлением обширного реинжиниринга. Соответственно, в этом случае подразделения могли бы работать на реализацию значительных изменений стандартных объектов и процессов (см., например, Hammer 1990).
Указанные причины дают основание предполагать, что подразделения имеют стимулы склонить корпорацию к выбору стандартов, благоприятных для конкретных подразделений. Таким образом, компаниям необходимо подумать о том, как выбрать эти общие и глобальные стандарты.
Методы выбора стандартов
Как организации, внедряющие ERP систему, выбирают общие объекты и процессы? Как было отмечено существует множество источников ERP стандартов, и затраты для конкретных подразделений будут варьироваться в зависимости от того какие стандарты выбраны для внедрения.
Как организации решают, какие стандарты (например, списки поставщиков или продукции) принять? Как отмечают МакАфи и Аптон (McAfee and Upton 1996), у компаний есть вопросы относительно того, как выбирать стандарты для ERP систем. Например, авторы цитируют проект-менеджера, который говорит, что он отдает предпочтение МОПам. «реализуемым многими, разработанным немногими»,
ERP СИСТЕМЫ
но не знает, как реализовать это выражение на практике. Как достигается «реализуемый мно「к!М14»? Какие правила группового выбора использовали фирмы?
Решение большинством голосов
Согласно Вокину (Wakin 1998), СЮ компании Pirelli, там используется то, что он называет «демократическим управлением» подразделениями для достижения стандартизации в ключевых сферах бизнеса, необходимых для внедрения ERR Хотя демократическое управление может принимать мн。「弘6 формы, он предполагает подход «выбор большинства» — какой бы стандарт ни выбрало большинство подразделений, он становится корпоративным стандартом. Правило «выбор большинства» — это такое правило, при котором компания принимает МОП х вместо МОПа у, если большинство подразделений предпочитает МОП х.
Правило Борда
Альтернативным методом выбора «ввода многими» является (а) голосование членов группы специалистов путем ранжирования вариантов по убывающей, и затем (б) суммирование количества первых мест (вторых мест и т. д.), полученных каждым вариантом. Например, если существует пять различных путей реализации биз- нес-процесса «резервирование запасов для клиентов», то каждый член группы оценит варианты баллами от 1 до 5. Каждое полученное процессом 1-е место оценивается в 5 баллов (2-е место — в 4 балла и т.д.). По правилу Борда (см., например, Fishburn 1997) выбранным считается вариант, получивший большее количество баллов.
Из интервью с заместителем директора компании Litton Data Systems по внедрению системы PeopleSoft выяснилось, что компанией был использован метод, похожий на правило Борда. Во-первых, компания определила «ключевые аэрокосмические и оборонные характеристики и обязательства», среди них:
бизнес-процессы оборонной промышленности:
правительственные формы,
промежуточные выплаты,
скользящее среднее значение фактической стоимости;
финансовое управление:
бюджетирование и планирование ресурсов подразделений,
управление издержками,
соотношение между накладными расходами и оплатой труда.
Во-вторых, после получения этих и других требований, различные производители ERP систем были оценены и ранжированы в соответствии с их возможностями обеспечения каждой из характеристик. При этом соответствующим местам были присвоены баллы (как только что было описано). В-третьих, был сделан выбор ERP системы, исходя из окончательной оценки, определяемой общей суммой баллов.
Оптимальность Парето
Как отмечалось выше, СЮ компании Pirelli осуществляет, как он говорит, «демократическое управление» для достижения стандартизации в ключевых сферах бизнеса, необходимой для внедрения ERP (Wakin 1998). Оптимальность Парето — это критерий выбора из пар стандартов ERP путем оценки преимуществ для каждого подразделения. Конечно, если все ор「анмзаи弘оннне единицы остановятся на процессе х, а не у, то выбирается процесс х. В более типичном случае, когда подразделения не соглашаются на оказание поддержки различным процессам, решение «оптимальность Парето» является выбором, коща ни один другой выбор не может (а) удовлетворить ни одно подразделение в большей степени без того, чтобы не (б) удовлетворить любое дру「об подразделение, пусть в меньшей степени.
Диктатура
В дру「弘х ситуациях очевидно, что решение, использованное при выборе стандартов ERP системы, ближе не к подходу «выбор большинства», а к диктатуре. Например, при обсуждении компании Owens Corning было отмечено: «Команде Толедо было бы сравнительно легко собраться и выбрать процессы SAP для компании в одностороннем порядке» (СЮ 1996).
Другой пример (Brownlee 1996)——компания Colgate, внедрившая сеть запасов, «управляемых поставщиками» (для своих клиентов и поставщиков), используя SAP. Colgate обеспечила нескольких своих самых важных поставщиков системой SAR чтобы они могли получить непосредственный доступ к ее ERP системе. В результате ей не нужно платить за ингредиенты продуктов, пока она их действительно не использует. В данной ситуации Colgate определила многие бизнес- процессы, предоставила стандарты в отношении различных прайс- листов и т. д.
Подразделение может стать «диктатором», если это подразделение корпоративного офиса с определенным видением мира или большое подразделение с относительно значительной властью.
Какой метод лучше?
Выбор МОПов может оказать на деятельность фирмы позитивное влияние, поэтому он важен. Хотя существует несколько рациональных подходов, ни один из них не является лучшим в абсолютно любой ситуации. Таким образом, выбор МОПов является зачастую политическим процессом.
Резюме
До внедрения ERP систем фирмы в целом не использовали общие и глобальные модели, объекты и процессы (МОПы). Однако внедрение ERP систем обычно требует общих МОПов по нескольким причинам: требования системы, обслуживание клиентов, управление процессами, общекорпоративная БД, создание ценности и снижение расходов.
Обычно компании создают набор стандартов, выбирая из существующих у них МОПов (найденных в различных подразделениях), лучших практик, предоставленных консультантами и ERP системой, а также используя смешанные подходы. К сожалению, чаще всего не понятно, какой набор объектов и стандартов должен быть принят, особенно из-за того, что при любом выборе одни подразделения получат большую выгоду, чем другие. Стандартизация МОПов может быть довольно широкой, а подразделениям может быть разрешено выбрать только около 1% МОПов.
Из-за ограниченного числа вариантов выбора МОПов и их важности для отдельных подразделений выбор МОПов может привести к эмоциональным конфликтам. Следовательно, важно исследовать рациональные методы, которые были успешно использованы другими фирмами. Например, это может быть решение большинством голосов, правило Ворда, оптимальность Парето и диктатура.
Литература
Bashein, В„ Markus, L, and Finley, J. (1997). Safety Nets: Secrets of Effective Information Technology Controls. Morristown, NJ: Financial Executives Research Foundation.
Brownlee, L. (1996). «Overhaul». Wall Street Journal, November 18.
CIO (1996). «SAP Key Roles», (www.cio.com/forums/061596_sap_roles.html).
Fishburn, R (1971). «А Comparative Analysis of Group Decision Methods».
Behavior Science, November, pp. 538-44.
Hammer, М. (1990), «Reengineering Work: Don*t Automate, Obliterate». Harvard Business Review, July/August, pp. 104-12.
McAfee, A., and Upton, D. (1996). «Vandelay Industries». Report no. 9-697-037, Harvard Business School, Cambridge, MA.
Vaughn, J. (1996). «Enterprise Applications». Software Magazine, May.
Wakin, E. (1998). «Global Strategies Drive Pirelli». Beyond Computing, January/February, pp. 46-8.
White, J., Clark, D., and Ascarelli, S. (1997). «This German Software is Complex, Expensive and Wildly Popular». Wall Street Journal, March 17, p. 1.
11
ВНЕДРЕНИЕ ERP СИСТЕМ
«Сразу» против «Поэтапно»
«Поэтапно» и «сразу» — это два основных (и противоположных) метода, используемых для внедрения ERP систем. В данной「лаве рассматривается значение этих двух понятий, некоторые характеристики каждого из методов и некоторые их достоинства и недостатки. Здесь также анализируется выбор мбтодоло「1414 внедрения с учетом размера организации, ее сложности и структуры, а также с точки зрения объема внедрения. Наконец, обсуждаются некоторые дополнительные понятия и методы, используемые при внедрении ERP систем.
Что значит внедрение «сразу»?
При внедрении «сразу» полный набор приложений ERP внедряется во всех подразделениях одновременно. При внедрении «сразу» система из тестовой версии превращается в настоящую систему, используемую для проведения операций, за считанные дни (отсюда и название «сразу»). Этот подход требует одновременного внедрения множества модулей. В случае компании Quantum (см. приложения к данной главе) это означало внедрение 17 модулей приложений Oracle в 23 подразделениях по всему миру за время, равное примерно неделе. В соответствии с этим сценарием внедрение «сразу» требует выполнения до перехода от традиционных систем к новой системе многочисленных тестирований. В случае с компанией Quantum это означало от шести до восьми месяцев тестирования системы,
173
缪 ：
прежде чем произошел запуск и началось ее реальное использование для обработки деловых операций.
Обычно подход «сразу» предусматривает три этапа. На первом выбираются (или разрабатываются) и реализуются в ПО практически все значимые процессы и объекты. Для компании Quantum этот этап проходил примерно с января по август 1995 г. На втором этапе тестируются все модули порознь и их взаимодействие с другими модулями. У компании Quantum эта стадия проходола примерно с сентября 1995 г. по апрель 1996 匚 Проблемы, выявленные на стадии тестирования, подготавливают почву для дальнейшей разработки и установки модулей. На третьем этапе старая система «отключается» и «включается» новая. После внедрения всегда дополнительно требуются незначительные изменения, однако поскольку проводилось обширное тестирование, есть надежда, что удастся обойтись без серьезных изменений.
Что такое поэтапное внедрение?
Метод поэтапного внедрения ——это метод, при котором внедряется один модуль из группы модулей, причем зачастую только в одном подразделении. Поэтапное внедрение — это последовательное внедрение, состоящее из проектирования, разработки, тестирования и установки различных модулей. В отличие от внедрения «сразу», поэтапное внедрение требует, чтобы было уделено значительное внимание традиционным системам и проводилось их обслуживание для обеспечения (на каждой стадии) их 弘нтб「рещим с новой ERP системой.
По сравнению с внедрением «сразу» поэтапному методу соот- ветствуют более мелкие «доли» проектирования процессов и объектов модулей, их разработки, тестирования и внедрения. Компания Siemens, например, использовала трехэтапное внедрение SAP (Hirt and Swanson 1998). На первом этапе компания внедрила модули финансов, управления, дебиторской и кредиторской задолженности и модуль закупок. Работы по проектированию, разработке, тестированию и внедрению для пбрво「о этапа должны были завершиться в период с октября 1995 匚 по сентябрь 1996 г На втором этапе, в период с октября 1996 г. по апрель 1997 匚 должны были быть установлены модули управления материалами, промзводствбнно「о планирования и планирования качества. Наконец, остальные модули планировалось спроектировать, разработать, протестировать и внедрить в период с апреля 1997 匚 по сентябрь 1997 г.
Каковы преимущества метода «сразу»?
Отсутствие потребности8 создании временных интерфейсов
При внедрении «сразу» существующие традиционные системы в основном оставляют без изменений до полной их замены. Так как заменяются несколько традиционных систем одновременно, метод «сразу» не требует создания временных интерфейсов. Если метод «сразу» не используется, внедрение с множеством связей с традиционными системами может потребовать значительных ресурсов.
Меньшая потребность в обслуживании
и модификации традиционного ПО
Так как использование метода «сразу» влечет за собой немедленный переход от традиционных систем к новой ERP системе, нет большой потребности во времени и ресурсах на обслуживание или изменение традиционных систем. Таким образом, при использовании метода «сразу» фактически все ресурсы на обслуживание и разработку, необходимые при использовании поэтапного метода, могут быть направлены на разработку и тестирование новой системы.
Меньший риск
При поэтапном внедрении члены команды задействованы в разных этапах внедрения различных модулей. При внедрении же «сразу» вся проектная команда работает над проектом примерно в одно и то же время. Таким образом, некоторые (например, Хенк Делевати, СЮ компании Quantum) заявляют, что метод внедрения «сразу» имеет меньший риск по сравнению с поэтапным внедрением: «Поэтапный подход более рискован, поскольку не возможно вовлечь всех и координировать их действия» (Radosevich 1997). Кроме то「о, при подходе «сразу» риск потерять служащих до завершения их обязательств по внедрению меньше. А опыт участников внедрения до его завершения не является «полным». Таким образом, при подходе «сразу» вероятность того, что участники внедрения останутся на фирме до б「。окончанк!я, более высока.
Объединение функциональных возможностей
Желаемая функциональность может потребовать стыковки множества модулей. В этом случае, прежде чем функциональные характеристики станут доступными, такие модули должны быть
внедрены («доступно по обещанию» ——одна из таких характеристик). Так как при подходе «сразу» одновременно внедряются все модули во всей ор「ан^за1Ц1% их стыковка может быть произведена быстрее, и пользователям не придется долго ждать функциональных характеристик, которые задействуют возможности нескольких модулей.
Обратной дороги нет
При внедрении «сразу» традиционной системы, к которой можно вернуться, больше не существует. Таким образом, фирмы должны продвигаться вперед с новой системой, даже если есть определенные проблемы. Зная, что доро「и назад нет, проще не оглядываться. Это также может обеспечить приверженность системе, которой, в противном случае, могло бы не быть.
Более быстрое внедрение
Одной из причин неудачных проектов внедрения ERP систем является слишком продолжительное (зачастую длящееся 1-3 года) внедрение. Длительное внедрение может не оказаться успешным по нескольким причинам. Чем больше времени занимает внедрение, тем (а) изменится большее число требований, (б) больше ве- роятностьто「。，что персонал, задействованный во внедрении, сменится, и (в) больше времени будет у оппонентов проекта на работу ПРОТИВ Н6ПХ
Хотя на продолжительность внедрения почти всегда влияет объем ресурсов, задействованных для выполнения задачи, ни подход «сразу», ни поэтапный метод не занимают однозначно большее совокупное время на внедрение. Однако, так как при подходе «сразу» проектирование, разработка, тестирование и внедрение всех модулей проходит одновременно, внедрение при этом обычно занимает меньше времени. Такое внедрение может проводиться быстрее также 6ла「одаря отсутствию необходимости создавать временные интерфейсы с традиционными системами (как при поэтапном внедрении).
Стоимость
Какой из подходов является более доро「остоя山им? Если все проходит хорошо, без неожиданностей, подход «сразу», возможно, повлечет меньше расходов, так как, как минимум5 требуется меньше работы с существующими системами и временными интерфейсами.
Каковы преимущества поэтапного внедрения?
Пиковые требования к ресурсам меньшегчем при внедрении «сразу»
Некоторые фирмы, такие как Siemens (Hirt and Swanson 1998), выбрали поэтапный метод из-за о「раничбнности ресурсов. В то время как метод «сразу» требует единовременного использования ресурсов значитбльно「。обьема, при поэтапном методе эти пиковые требования к ресурсам можно распределить по этапам. При таком внедрении ресурсы, требующиеся для любого конкретного этапа, могут быть о「ранк!ченз и быть доступными даже для ор「анк!зещ14й с самыми о「ранмчбнным弘 ресурсами.
Для какого-то конкретного модуля
могут быть выделены большие ресурсы
При необходимости фактически все ресурсы фирмы на проектирование, разработку и тестирование могут быть сосредоточены на одном конкретном этапе и модулях, внедряемых на этом этапе. В этом состоит отличие позтапно「。внедрения от внедрения «сразу», при котором ресурсы должны быть одновременно распределены между мно「очислбнннм弘 модулями. Этот вопрос может быть важным для фирм с о「ранмчбнным弘 ресурсами или резервом времени. При отсутствии достаточных ресурсов проект может подвергаться значительному риску неудачи.
Меньшие риски
Подход «сразу» ——это подход «все или ничего». Один неисправно работающий модуль при подходе «сразу» может вызвать провал все- 「о внедрения. В результате некоторые фирмы могут решить, что при использовании тако「。метода возможность сбоя всей системы слишком велика, или что они могут чувствовать дискомфорт из-за необходимости сделать ставку на подход «все или ничего». Поэтапная стра- те「弘я обычно рассматривается как меньший риск.
Отступление при помощи традиционной системы
При внедрении «сразу» традиционная система отключается. Это означает отсутствие альтернативы, если (скажем, из-за неисправности одной ее части) вся система не будет функционировать. Так как при использовании поэтапного метода ERP система устанавливается по частям, у организации есть большая возможность убедиться, что модуль работает, прежде чем альтернативная система будет отклю-
чена. Поэтапный метод, таким образом, более консервативен, так как он обеспечивает дублирование.
Персонал получает знания на каждом этапе
При поэтапном внедрении знание, полученное на одном этапе, может быть применено на других этапах. Персонал, работавший на одном этапе, может использовать знания, уже полученные при внедрении, на более поздних этапах. Таким образом, модули могут проектироваться людьми, получающими все больший опыт, так как проектная команда может оказывать влияние на вопросы проектирования, разработки, тестирования и внедрения. Это преимущество менее значительно, если большая часть работы делается внешними консультантами, хотя и они тоже могут получить знание на одном этапе, которое будут использовать на другом этапе (если даже это знание специфическое для конкретной организации),
Проект-менеджеры могут продемонстрировать работающую систему
При поэтапном внедрении, чтобы показать остальной компании, что система работает, может быть использовано успешное внедрение какого-либо модуля. Получение хороших результатов может быть необходимо в ситуациях, когда поначалу не существует полной поддержки проекта организацией или ее топ-менеджментом. Успех на одном этапе может быть использован для демонстрации менеджменту 丁。「。，что система может и будет работать.
Если это основная причина, по которой фирма использует поэтапный метод, скорее всего в первую очередь будут внедрены «самые простые» модули. Например, в первую очередь будут внедрены модули, требующие проведения лишь минимального реинжиниринга. Это можно увидеть на примере компании Siemens (Hirt and Swanson 1998), где возможности первого внедренного программно- 「о пакета почти полностью соответствовали требованиям фирмы.
Сокращается время между разработкой и использованием
К сожалению, при внедрении «сразу» период между разработкой системы и ее фактическим использованием в производстве может быть длительным. Таким образом, участники внедрения определённого модуля могут не видеть связи между разработкой и внедрением, и их беспокойство может стать потенциальным риском для проекта. Связь между разработкой и запуском при поэтапном внедрении обычно более тесная.
Каковы недостатки?
Подход «сразу»
Недостатки подхода «сразу» прямо противоположны преимуществам позтапно「。внедрения:
могут потребоваться огромные пиковые ресурсы;
для конкретного модуля будет доступно меньше ресурсов;
риск полно「。отказа системы может быть выше;
нельзя без труда вернуться к традиционной системе;
у персонала меньше практической возможности приобрести знания;
проект-менеджеры не могут показать, что система работает, до полной ее установки;
период между разработкой и внедрением может быть более длительным.
Поэтапное внедрение
Недостатки поэтапного внедрения прямо противоположны преимуществам внедрения «сразу»:
широкое использование временных интерфейсов;
необходимость обслуживания и модификации традиционного ПО;
более высокий риск, связанный с незадействованным персоналом и его нескоординированной работой;
более высокий риск смены персонала в ходе реализации проекта;
может быть внедрено недостаточно модулей для обеспечения необходимых функциональных возможностей;
действующая традиционная система дает возможность отступления, что может помешать внедрению новой системы;
более длительная установка;
более высокая общая стоимость.
Характеристики организации и методология внедрения
Выбор метода внедрения должен производиться, исходя из анализа затрат и результатов с учетом риска. Однако риск и положительные результаты трудно оценить. Таким образом, организации выбирают методы внедрения, исходя из других параметров, таких как пиковые ресурсы, функциональные возможности, поддержка менедж-
ERP СИСТЕМЫ
мента и риск. Существуют также другие переменные, которые могут повлиять на принятие решения. В частности, среди этих переменных такие характеристики организации, как размер, сложность, структура и управление.
Размер и сложность организации
Размер и сложность организации являются важными переменными, от которых зависит выбор подходящего метода внедрения. В целом, менее крупные и сложные организации используют метод внедрения «сразу», в то время как более крупные, более сложные организации используют поэтапные методы. По мере возрастания размера и сложности фирм потенциальная возможность использования ими поэтапного метода возрастает. Эта тенденция отображена на рис. 11.1.
Размер и сложность организации. Сложность организации имеет несколько источников, включая ее продукцию и клиентов. Например, фирмы с большой номенклатурой продукции или большим числом клиентов обычно более сложные. Сложность также может зависеть от характеристик клиентов или продукции. Например, наличие более влиятельных клиентов приводит к большей сложности, чем наличие менее влиятельных клиентов, так как влиятельные клиенты могут воздействовать на процессы, используемые при проектировании системы. Линейка продуктов также может влиять на сложность. Например, фирма с более широкой номенклатурой продуктов будет иметь более сложную систему, чем фирма с более узкой продуктовой линейкой.
Рис. 11.1. Связь между размером и сложностью организации и используемым методом внедрения
SXX05
Размер фирмы также может зависеть от нескольких факторов. Хотя классическая оценка фирмы — это доходы или общая стоимость имущества, другими факторами могут быть количество офисов или географических регионов, в которых она расположена. Для оценки размера организации могут быть также использованы ее продукция и клиенты.
Малые, менее сложные фирмы. Менее крупные и менее сложные фирмы будут иметь меньшее разнообразие продукции и клиентов. Таким образом, внедрение ими соответствующего проекта не является таким трудным, как в более сложных фирмах. Кроме того, так как их размер небольшой, а проект несложный, риск неудачного внедрения, связанный с внедрением «сразу», будет меньше. Соответственно, так как внедрение «сразу» в целом проходит быстрее и требует меньших расходов, менее крупные и сложные фирмы могут эффективно использовать этот метод.
Крупные, более сложные фирмы. Если фирма очень крупная и сложная, то, скорее всего, будет использовано поэтапное внедрение, а не внедрение «сразу». Размер и сложность организации могут сделать или слишком сложным метод внедрения «сразу», или слишком высоким риск провала, что приведет ее к выбору поэтапного метода. Аналитики (такие, как Бобби Кэмерон из Forrester Research) предположили, что большинство крупных фирм используют одну из версий поэтапного внедрения и что только небольшое количество крупных фирм используют внедрение «сразу»:
Слишком сложно ——особенно для крупных компаний ——осуществлять крупный проект,... и риск с точки зрения проектного менеджмента —высок,.. Огромные проекты одновременного внедрения достаточно сложны, и большинство стремятся к менее крупному постепенному внедрению. (Radosevich 1997).
Кроме того, для крупных фирм требования пиковых ресурсов для внедрения могут оказаться слишком высокими.
Иерархия организации и управление
Даже если все остальные организационные аспекты одинаковы, при выборе методологии должна учитываться иерархия и управляемость организации. В целом, по мере того, как организация становится более иерархической с большей управляемостью, она все больше становится способной выдержать поэтапное внедрение. Это отношение представлено на рисунке 11.2.
sstlBESHE-ldo BdEAdssstlBESHE-ldo BdEAdsСтепень управляемостиСтепень управляемостиРис. 11.2. Связь между иерархией и управлением организации и используемым методом внедренияРис. 11.2. Связь между иерархией и управлением организации и используемым методом внедренияKioxmoso^ox^- к^ооёKioxmoso^ox^- к^ооё
sstlBESHE-ldo BdEAds
sstlBESHE-ldo BdEAds
Степень управляемости
Степень управляемости
Рис. 11.2. Связь между иерархией и управлением организации и используемым методом внедрения
Рис. 11.2. Связь между иерархией и управлением организации и используемым методом внедрения
Kioxmoso^ox^- к^ооё
Kioxmoso^ox^- к^ооё
Горизонтальная организация и нежесткое управление. Бобби Кэмерон из Forrester Research предположил, что некоторые характеристики компании должны привести к использованию метода внедрения «сразу»: «Если компания имеет горизонтальную, нежестко управляемую организацию, то поддерживать проект на протяжении поэтапного внедрения очень трудно» (Radosevich 1997).
Значительная иерархия и жесткое управление. Если структура организации имеет значительную иерархичность (организация является «многоуровневой»), и организация управляется жестко, то в организации существует значительный аппарат для проведения поэтапного внедрения* Кроме того, из-за наличия организационной структуры и управления на местах может оказаться, что поэтапный метод (без значительного реинжиниринга) является единственным политически приемлемым.
Масштабы внедрения
Масштабь( внедрения, характеризуемые числом модулей и степенью их изменения организацией, также могут повлиять на методологию внедрения, как показано на рисунке 11.3.
Число модулей
Так как ERP системы состоят из модулей, организации могут решить внедрить различные модули, которые отвечают их требованиям. Например, корпорация Microsoft при внедрении SAP R/3 устано-
so^ss x-qweHdaeHm 0mH00^s§^so^ss x-qweHdaeHm 0mH00^s§^МинимальнаяВысокаяСтепень изменения модулей ERPРис. 11.3. Связь между методом внедрения и модулями ERPМинимальнаяВысокаяСтепень изменения модулей ERPРис. 11.3. Связь между методом внедрения и модулями ERPфоахёш фоахвюфхфоахёш фоахвюфх
so^ss x-qweHdaeHm 0mH00^s§^
so^ss x-qweHdaeHm 0mH00^s§^
МинимальнаяВысокая
Степень изменения модулей ERP
Рис. 11.3. Связь между методом внедрения и модулями ERP
МинимальнаяВысокая
Степень изменения модулей ERP
Рис. 11.3. Связь между методом внедрения и модулями ERP
фоахёш фоахвюфх
фоахёш фоахвюфх
вила только финансовый модуль. Другие организации внедряют полный набор приложений ERP систем.
По мере увеличения числа модулей их взаимодействие становится координировать все труднее. Кроме того, увеличиваются ресурсы, требующиеся из расчета каждого модуля, выбранного для внедрения, В результате по мере увеличения числа модулей происходит сдвиг от внедрения «сразу» к поэтапному внедрению.
Соответствие модуля: масштабы модификации
В некоторых случаях модули могут требовать только ограниченной модификации, но в других случаях может потребоваться значительная модификация. Например, как было отмечено в случае с компанией Siemens (Hirt and Swanson 1998), финансовые модули соответствуют требованиям фирмы на 100%, а другие модули только на 70-80%, и, таким образом, требовалась некоторая модификация.
По мере увеличения масштабов изменения модулей предпочтение будет отдаваться поэтапному внедрению. Если используемые модули фактически остаются такими, как их задумал и разработал производитель, проблемы взаимодействия будут минимальными.
Небольшое число модулей и минимальные изменения
Если изменения в модулях минимальны, то тестирование по большей части ограничивается сценариями, протестированными производителем, который гарантирует, что модули были установлены правильно и что лучшие практики взаимодействуют друг с другом должным образом. Конечно, если установлено только небольшое число модулей, то столько взаимодействий тестировать будет не
нужно. Это означает, что организация, решающая внедрить небольшое число модулей с минимальными изменениями, скорее всего, будет использовать метод «сразу».
Большое число модулей и значительные изменения
Изменения в ПО увеличивают уровень сложности внедрения. В частности, эти изменения привносят большую возможность ошибок и вызывают необходимость большего тестирования этих изменений — и конкретных модулей, и тех модулей, с которыми они взаимодействуют. Необходимость внедрения большого числа модулей приводит к увеличению уровня сложности. Следовательно, если организация решила внедрять много модулей, и если для некоторых из них потребуются значительные изменения, будет использоваться поэтапный метод. По сути, необходимость поэтапного внедрения может возникнуть из-за его высокой сложности.
Альтернативные методы внедрения
Стали использоваться и некоторые другие понятия, обозначающие методы внедрения ERP систем, среди них ——«волнообразный» и «ускоренный поэтапный» методы. Кроме того, существует такое понятие, как «параллельное функционирование».
Внедрение《волнами»
Компания Tektronix использовала альтернативный метод, называемый волнообразным (Westerman и др. 1999). Внедрение ERP системы этой компанией рассматривалось как программа изменений, состоящая из различных «волн» изменений. Каждая «волна» программы привносила в различные организационные единицы или географические регионы новые исполняемые функции. Хотя каждая волна управлялась независимо, чтобы гарантировать, что программа изменений выполняется, общая проектная команда управляла их взаимозависимостями. Например, компании Tektronix понадобилось три года на внедрение приложений Oracle. За первый год в 16 странах была внедрена Главная книга. Затем компания сфокусировалась на конвертации дебиторской задолженности и управлении стоимостью в своих региональных учетных центрах по всему миру. После внедрения финансовых приложений Tektronix смогла добавить новые возможности (например, отчеты о заказах, биллинг и задолженности) в информацию о продукции своих организационных единиц.
«Волнообразный» подход обеспечивает несколько преимуществ. Во-первых, каждая волна показывает то, как идет внедрение системы и как она принимается. Во-вторых, с каждой успешной «волной» растет моральный дух команды. В-третьих, обеспечивается гибкость: если выходит новая версия ERP системы, менеджеры программы могут добавить новую «волну».
Ускоренный поэтапный метод
Хотя некоторые организации (по каким-либо причинам) не хотят проводить внедрение «сразу», они все же могут использовать так называемый ускоренный поэтапный метод. Данный метод предполагает, что вре'менные связи с традиционными системами являются действительно временными, а не почти неизменными. Кроме того, при использовании данного метода одновременно могут быть внедрены несколько модулей.
Параллельное функционирование
Классическая стратегия внедрения ——параллельное функционирование. Если внедряется ERP система, то организация на какой-то период времени (обычно это месяц или квартал) запустит ее вместе с существующей системой для того, чтобы убедиться, что ERP система работает так, как предполагалось. Данный метод может быть использован независимо от числа внедряемых модулей.
Параллельное функционирование имеет несколько преимуществ. Старая система обеспечивает базис для сравнения, позволяя увидеть, работает ли система так, как предполагалось. Кроме того, старая система обеспечивает поддержку на случай, если новая работать не будет. Таким образом, параллельное функционирование часто рассматривается как решение с низкой степенью риска.
К сожалению, параллельное функционирование имеет некоторые недостатки. Во-первых, оно требует примерно вдвое больших вычислительных ресурсов и персонала — это существенные расходы, возможно, на длительный период. Кроме того, хотя идея параллельного функционирования ——это тестирование новой системы, сравнение ее со старой и выяснение, правильно ли она проводит деловые операции, существуют причины полагать, что старая система может не оказаться хорошей базой для сравнения. Те, кто управлял старой системой, теряют стимул для поддержания ее работы, так как по окончании тестирования она будет заменена. В результате, в ней могут появиться серьезные ошибки. Более того, если старая система функционирует, то некоторые могут не видеть необходимости про-
должать внедрение новой системы. Следовательно, продолжительное существование традиционной системы может угрожать новой системе.
Реинжиниринг изменяет процессы и требования к информации. В результате традиционная и новая системы могут иметь мало общего между собой, и старая система может не быть содержательной основой для сравнения. Следовательно, если был проведен обширный реинжиниринг; параллельное функционирование не будет подходящей стратегией.
Резюме
В данной главе представлен анализ достоинств и недостатков поэтапного внедрения и внедрения «сразу». Кроме того, также представлен «волнообразный» метод, находящийся ще-то между этими двумя методами.
Какой метод оптимален, и какой должна выбрать фирма? Представленные в данной главе примеры позволяют говорить о том, что оптимального метода для всех ситуаций не существует. Чтобы решить, какой метод нужно выбрать, фирмам необходимо исследовать такие факторы, как их размер, сложность, управление и иерархия. Кроме того, фирмам необходимо оценить относительные достоинства и недостатки разных методов, прежде чем решить, какой из них подойдет для них лучше.
Литература
Hirt, S., and Swanson, Е. В. (1998). «Adopting SAP at Siemens Power Company».
Paper presented at the International Conference on Information Systems (Helsinki), December.
Radosevich, L. (1997). «Quantum's Leap». CIO Magazine, February 15.
Westerman, G , Cotteleer, M., Austin, R., and Nolan, R. (1999). «Tektronix:
Implementing ERP». Report no. 9-699-043, Harvard Business School, Cambridge, MA.
Приложение 11-1
Quantum I:требование выбор системы и метод внедрения^
Хенк Делевати, СЮ и вице-президент международной информационной службы компании Quantum, заметил:
Нам крайне важно соответствовать нашим клиентам и нести перед ними ответственность. А когда дело доходит до управления спросом и запасами в мировом масштабе [при использовании нашей информационной системы, у нас сделать это не получается]...
В результате, для реализации своих потребностей компания Quantum планировала купить систему планирования ресурсов предприятий. Ей необходимо было понять свои требования, какое ПО им отвечает и какой метод внедрения подойдет больше.
Quantum
Компания Quantum, главный офис которой расположен в Милпитасе, штат Калифорния, имела доход в 4,4 млрд, долларов. Она была одним из крупнейших производителей компьютерных запоминающих устройств, включая накопители на жестких дисках и ленте. В 1996 匚 Quantum была вторым крупным производителем дисков для серверов, производя более 6 млн. дисков. В 1996 匚 компания была также самым большим производителем, продающим накопители на жестких дисках для персональных компьютеров, реализуя их более 25 млн. У нее насчитывалось 23 подразделения по всему миру, имеющих предприятия, поставщиков и клиентов по всей Северной и Южной Америке, Азии и Европе.
Компьютерные запоминающие устройства — циклический бизнес с жесткой конкуренцией. В 1986 匚 во всем мире было 350 производителей дисковых накопителей. Однако десять лет спустя в США остались только четыре основные фирмы, производящие дисковые
накопители, включая Seagate, IBM, Western Digital и Quantum. Конкуренция на рынке остается жесткой; как заметил Делевати:
Дисковые накопители стали выгодным делом. Дисковые накопители компании Quantum известны своим качеством, мы продаем надежные дисковые накопители с высокими функциональными возможностями, скоростью и производительностью. Но клиенты всегда хотят чего-то с большими возможностями, более быстрым доступом и по менее высокой цене. Нам нужно быть в этом среди первых.
Хотя компании Seagate и IBM проектируют, производят, собирают, распространяют и продают свои накопители самостоятельно, компания Western Digital производит свои накопители в сотрудничестве с другими фирмами. Quantum отличалась от других крупных производителей тем, что производство было выведено за рамки компании, и компания занималась сбытом и маркетингом.
Бизнес-стратегия Quantum
В то время как дисковые накопители пользовались все большим спросом, стратегия Quantum заключалась в том, чтобы сделать своим конкурентным преимуществом работу с клиентами. Как сказал Делевати: «Наша бизнес-модель ориентирована на наших клиентов. Наши отношения с клиентами стоят на первом месте ——они важнее технологии, ценовых характеристик и конструктива».
Информационные системы Quantum
Quantum была ограничена в своих возможностях обслуживать клиентов. В ней использовались девять различных традиционных систем, которые поддерживали работу ее бизнес-единиц, но не обеспечивали им доступ к информации других бизнес-единиц. В результате бизнес-единицы компании функционировали наполовину автономно, что затрудняло координацию при обслуживании клиентов.
Весной 1994 匚 проблемы информационных систем компании Quantum были типичными проблемами традиционных систем, на которых они базировались. Система материального планирования (MRP) AskManMan хранила деловые операции каждого подразделения в БД отдельных функциональных и бизнес-единиц. Так как БД не могли обмениваться информацией, эта информация объединялась вручную. Поэтому процесс сбора факсов, электронной почты и текстовой информации для MRP занимал четыре дня. Закрытие бухгалтерских книг занимало, по меньшей мере, 17 дней. Запасы, дебитор-
ская и кредиторская задолженность ——все это требовало сбора и обработки для отчетности.
Даже внутри компании информация о заказах была ограничена. Наличие запасов не могло быть подтверждено, и доставка могла занять несколько дней или недель. Чтобы обработать заказ, нужно было собрать информацию из множества точек дистрибуции по всему миру. На это также могло уйти несколько дней или недель. К сожалению, если доставка занимала слишком много времени, заказы могли быть аннулированы. Как сказал Марк Джексон, вице-президент компании: «Наша работа была ... ниже всяких норм».
Ситуация усложнилась, когда в октябре 1994 匚 Quantum приобрела бизнес систем хранения информации компании Digital Equipment Corporation (DEC). Эта компания имела финансовую систему собственной разработки наряду с другой традиционной системой MRP под названием Maxcim, разработанной компанией Computer Associates. Кроме того, DEC имела несколько различных традиционных систем, которые не могли взаимодействовать друг с другом. В результате менеджеры и сотрудники отдела продаж компании DEC не могли вовремя получать информацию в масштабах всего предприятия. Кроме того, при приобретении удвоилось число объектов системы компании Quantum (например, списки продукции, номера поставщиков и клиентов). Наконец, после приобретения DEC число служащих и процессов, используемых Quantum, также примерно удвоилось.
Для реализации стратегии обслуживания клиентов компании Quantum необходимо было предоставить возможность персоналу отдела продаж принимать и подтверждать заказы в реальном времени. Эти задачи требовали возможности оценки текущих запасов и резервирования заказа для клиента в реальном времени. Возможность подтвердить и распределить запасы была названа возможностью «доступно по обещанию» («available to promise», АГР). Традиционные системы не имели такой возможности. В отличие от традиционных систем, АГР могло быть обеспечено только множеством географически распределенных подразделений и множеством модулей. То есть, АГР могло быть использовано только при наличии достаточной инфраструктуры ERR
ERP-проект компании Quantum
В 1993 匚 Quantum признала наличие этих проблем со своими системами. В результате в апреле 1993 匚 ее подразделение информационных систем начало рассылать запросы с целью получения пред-
ложений по системе предприятия, которая отвечала бы нуждам компании. В марте 1994 匚 Quantum выбрала для оказания ей помощи в преодолении проблем существующих у нее информационных систем компании Oracle, Hewlett-Packard и Pricewaterhouse.
Проектная команда Quantum
Проектная команда Quantum с самого начала имела поддержку топ-менеджмента< Как сказал Джексон: «Чтобы преуспеть, необходимо потратить деньги и позаботиться о деталях». В апреле 1994 г. Quantum назначила членов проектной команды и назвала проект «WARP» (worldwide ask replacement system — запрос замены системы по всему миру). Ответственным за проект был назначен Майкл Браун, ставший позже СЕО компании. Под его руководством в течение лета 1994 г. Quantum создала три основные проектные команды. Во-первых, в руководящий комитет, возглавляемый Брауном, входили вице-президенты по финансам, информационным системам, материально-техническому снабжению, производству, закупкам и продажам, а также представители компании Price Waterhouse. Во-вторых, была образована основная команда, в которую вошли 16 менеджеров из нескольких подразделений и бизнес-единиц компании. В третьих, была сформирована проектная команда, состоящая из 100 человек, в которую входили сотрудники подразделения информационных систем и по несколько ведущих представителей каждой бизнес- единицы. Члены последних двух проектных групп были освобождены от своих повседневных обязанностей и полностью задействованы в проекте. Для разработки бизнес-процессов были организованы межфункциональные команды. На время работы над проектом члены групп были размещены в специальном месте.
Выбор системы планирования peq/рсов предприятий
После того, как команды были созданы, был проведен анализ существующих процессов. Используя игровые модели и другие методы, члены команд проанализировали и улучшили бизнес-процессы. Исходя из этих новых процессов, были установлены требования к новой системе. После рассмотрения различных пакетов программ, включая SAP R/3, Quantum решила внедрить БД Oracle 7, а также финансовые и производственные модули Oracle. Делевати отметил, что приложения Oracle были выбраны потому, что только они могли обеспечить возможность реализации ATR
Установка даты внедрения
После выбора Oracle Applications команды наняли дополнительное количество консультантов из Price Waterhouse и Oracle. Были запущены пилотные проекты. В конечном итоге, команды проекта WARP наметили внедрение на лето 1995 匚
Проблемы при внедрении
Проблемы возникли практически сразу. Приобретение компании DEC замедлило внедрение. Приобретение подразделения жестких дисков DEC усложнило проектирование и внедрение WARR Согласно Делевати: «Сложность и размеры проекта увеличились в четыре раза». Имело место дублирование систем, процессов и объектов. Кроме того, проектную команду попросили интегрировать новое приобретение в Quantum. Соответственно, пока шла работа над новым приобретением, проект WARP был приостановлен на три месяца.
В январе 1995 匚 проектная команда была собрана снова. Чтобы отразить расширение продуктовой линейки компании с учетом дополнительных объектов и процессов, ей было необходимо переделать свою изначальную работу. В связи с увеличившимся масштабом и из-за необходимости повторного выполнения уже сделанной работы руководящий комитет увеличил финансирование.
Поэтапное внедрение против внедрения «сразу»
Основным решением, которое предстояло принять менеджменту, было — использовать поэтапное внедрение или внедрение «сразу». Решение повлияло бы на разработку, тестирование и, в конечном итоге, на успешность внедрения.
При поэтапном внедрении компания обычно внедряет по одному модулю. В некоторых случаях внедряются по одному приложению в одном подразделении. При использовании этого метода на время внедрения ERP системы должны быть созданы временные интерфейсы между новыми модулям ERP и существующими традиционными системами.
При внедрении «сразу» фирма внедряет полный набор ERP-приложений одновременно во всех подразделениях. Для Quantum использование этого метода означало бы внедрение 17 модулей Oracle в 23 подразделениях по всему миру фактически одновременно.
Возникли споры по поводу того, какой метод выбрать. С одной стороны, Делевати заявлял: «Поэтапное внедрение — более дли-
тельное и более рискованное, так как будут задействованы не все специалисты, и действия не будут скоординированы». По поводу сложности поэтапного внедрения Бобби Кэмерон, старший аналитик из Forrester Research сказал: «Если компания имеет горизонтальную организацию, которая не управляется жестко, то очень трудно поддерживать проект на протяжении поэтапного внедрения». Однако Кэмерон также отметил, что большинство крупных фирм используют одну из версий поэтапного внедрения и что небольшое число крупных фирм используют внедрение «сразу»:
Это слишком сложно — особенно для крупных компаний ——проводить крупный проект,... и риск, сточки зрения проектного менеджмента, высок... Огромные проекты одновременного внедрения достаточно сложны, и большинство рассматривает небольшие — шаг за шагом — внедрения. (Radosevich 1997)
Вопросы
Каким требованиям компании Quantum не удовлетворяли существующие у нее системы?
Как Quantum должна была выбирать объекты и процессы для своей ERP системы, особенно после того, как приобрела компанию DEC, и произошло дублирование бизнес-процессов?
Каковы достоинства и недостатки позтапнонэ внедрения и внедрения «сразу»?
Какой метод — поэтапный или «сразу» ——должна использовать Quantum? Почему?
Как вы считаете, какие фирмы будут использовать метод «сразу», а какие предпочтут поэтапный метод?
ПРИЛОЖЕНИЕ 11-2
Quantum II:внедрение «сразу»
При внедрении программного приложения Oracle Quantum решила использовать метод «сразу». Как сказал вице-президент Марк Джексон: «Если бы мы выбрали поэтапный метод, мы не смогли бы использовать АТР до полного внедрения системы. Нам пришлось делать внедрение «сразу».
Тестирование при внедрении «сразу»
Системная тестовая аттестация № 1
В рамках своего проекта внедрения «сразу» Quantum запланировала шестимесячное всестороннее тестирование системы. В действительности проверка заняла семь-восемь месяцев. Как сказал Марк Вито, менеджер консалтинговой группы Oracle, участвовавший в проекте: «[Обычно] планируются определенные шаги, такие как всестороннее тестирование систем, но в действительности они не реализуются... [Однако] в случае с Quantum это было не так». К сентябрю 1995 匚 каждая основная часть системы была протестирована в режиме, когда конкретный модуль тестируется на некоторых деловых операциях для того, чтобы убедиться, что он работает должным образом.
Чтобы осуществить более обширные тесты, Quantum собрала около 100 пользователей в главном офисе корпорации. Планировалось, что эта тестовая аттестация, названная «Системная тестовая аттестация № 1», продлится две недели. При этом должны были тестироваться возможности системы, включая оборудование. Пользователи осуществляли большое число операций, моделирующих работу системы, при требованиях, которые будут предъявлены ей в будущем.
К сожалению, это тестирование продлилось не больше недели. «Упала» сеть. Приложения не работали должным образом. Заказы не приводили к изменениям в производственных планах.
Изменения, вызванные системной тестовойаттестацией № 1
После возникновения проблем, выявленных системной тестовой аттестацией № 1, к Quantum с целью надзора за внедрением присоединился Хенк Делевати. Делевати уже имел подобный опыт при внедрении приложений Oracle в компании Sun Microsystems.
По мнению Делевати, некоторые из этих проблем возникли из-за оборудования и ПО в целом. В результате Quantum перешла на последнюю версию серверов Hewlett-Packard (HP) 9000 и операционную систему HP UX, Кроме того, компания модернизировала приложения Oracle, выбрав самую последнюю версию, — Oracle 10.4. Эта новая версия требовала множества качественно новых настроек и имела сотни новых реляционных таблиц БД, требующих конфигурирования.
Несмотря на наличие плана всестороннего тестирования некоторые аспекты тестирования остались незамеченными. Хотя отдел fa-
ные части проекта успешно прошли проверку, не была протестирована взаимозависимость различных частей системы. Как заметил Де- левати: «Для них было потрясением, что, хотя части системы по отдельности работали, они не могли работать вместе».
Чтобы подготовиться ко второму тесту, Делевати разработал организационную схему для выявления проблемных областей. Был составлен подробный список задач проекта WARP и назначен ответственный за каждую задачу. Среди категорий задач были бизнес-функ- циональность, производительность системы, преобразование данных, готовность информационных систем, обучение, документация и готовность отдельных подразделений. В рамках каждой задачи могли быть сотни подзадач. Каждая подзадача была обозначена цветом, обозначающим достигнутую стадию готовности:
зеленый = «готово»;
желтый 二 «требует доработки»;
красный = «еще не готово».
Когда подзадачи были обозначены цветами, команды смогли акцентировать внимание на задачах, обозначенных красным цветом.
Системная тестовая аттестация № 2
С каждым днем все большее число задач обозначались зеленым цветом. К началу декабря все задачи, ранее обозначенные красным, перешли в разряд «зеленых» или «желтых». При этом была очевидна важность успеха повторной системной тестовой аттестации. Как сказал Делевати:
Если бы вторая системная тестовая аттестация в мировых масштабах прошла неудачно, настрой команда! упал бы. Она должна была стать успешной.
Системная тестовая аттестация № 2 проводилась с 11 декабря 1995 е по8 января 1996 匚 Для участия в тестировании системы в главный офис корпорации прилетели пользователи со всего мира.
Хотя системная тестовая аттестация № 2 прошла хорошо, тесты выявили несколько областей, требующих дальнейшей работы. В результате Quantum назначила итоговое тестирование на февраль 1996 к В рамках этого тестирования «желтыми» из «зеленых» стали только те задачи, которые требовали дополнительного внимания при реализации WARR Например, в ходе тестирования сеть в Пенанге (Малайзия) оказалась близка к перегрузке. К сожалению, чтобы увеличить пропускную способность этой сети, понадобилось 90 дней. Чтобы избежать задер-
жек во внедрении, команда закрыла персоналу в Пенанге доступ в Интернет до момента увеличения пропускной способности сети ——вся ширина полосы была отдана под приложения Oracle.
Обучение
Во время внедрения и тестирования системы Quantum финансировала обучение пользователей. 24-месячный график внедрения предусматривал шестинедельное обучение в мировых масштабах. На время обучения, длящегося от двух до четырех недель, служащие были освобождены от работы. Джексон заметил: «Отношение к обучению было очень серьезным, и менеджерам на местах не разрешалось отвлекать служащих от обучения, независимо от возникавших проблем в бизнесе».
Внедрение «сразу»
К 26 апреля 1996 匚 большинство проблем проекта WARP было решено. В 17.00 по среднетихоокеанскому времени переход начался. Все записи были конвертированы и переведены в приложения Oracle. 3 мая был выполнен «моментальный снимок» данных и проведены некоторые операции. Вскоре после этого 100 членов проектной команды вошли в систему для работы с некоторыми образцовыми данными. Система работала. Пришло время внедрения «сразу».
5 мая Джексон запустил систему для реальной работы. Старшие менеджеры и проектная команда наблюдали за тем, как к системе подключаются пользователи со всего мира. Как заметил Делевати: «Это был волнующий момент, все были полны энтузиазма. Свое домашнее задание мы выполнили. Мы были уверены, что система будет работать». Кб мая 1996 匚 Quantum конвертировала дебиторские задолженности на сумму более 1 млрд, долларов и заказы на сумму 1,6 млрд, долларов, открытые во время внедрения. Система компании Quantum, насчитывающая более 1 300 пользователей по всему миру, стала самой большой распределенной системой приложений Oracle, внедренной с использованием метода «сразу».
Делевати отметил, что
бизнес, как мы и предполагали остановился. В течение восьми календарных дней мы не могли размещать заказы, не могли получать материалы, не могли осуществлять перевозки продукции. Мы даже не могли перевести деньги.
В ту неделю не могла быть проведена ни одна деловая операция, кроме операций с платежными ведомостями. Ничто (от запасов до закупок, от составления графиков до перевозок) не работало. Затем мы возобновили работу компании с многочисленными интегрированными подразделениями по всему миру.
Функциональные возможности приложений Oracle
В конечном счете, система задействовала девять серверов HP для поддержки более 40 000 таблиц реляционных БД. В Quantum приложения Oracle используются в основном для управления запасами и для финансовых операций. Установка Oracle позволила интегрировать в одной системе информацию и о наличии запасов, и о поставках. Таким образом, наличие запасов и сроки поставок могли быть подтверждены буквально в считанные минуты.
Внедрение системы имело и дополнительные преимущества. Как сказал Делевати:
Одно из самых очевидных преимуществ — это то, что все наши заказы, все наши запасы и все наши финансы консолидированы и централизованы. Это огромное конкурентное преимущество. До новой системы на закрытие бухгалтерских книг уходило, по меньшей мере, 17 дней. В первый месяц работы новой системы... мы закрыли книги за девять дней. А в конце первого квартала на это потребовалось только 11 дней.
Делевати также отметил: «В плане стратегии мы можем предугадывать, когда следует сворачивать производство одних продуктов и наращивать его для других и упреждать желания клиентов при планировании жизненного цикла. Это большое преимущество ——управлять данными в реальном времени в соответствии с маркетинговой информацией».
Затраты и результаты
По оценке Марка Джексона проект был столь же дорогим, как и разработка и создание новой предметно-производственной специализации. Хотя исследование возврата на инвестиции (ROI) не было проведено, для определения меры успешности внедрения, Джексон
считал, что проект внедрения был успешным, и комментировал свое мнение следующим образом:
Мы могли бы рассчитать, как сэкономить 10% расходов на проект, что было бы значительной суммой, но я думаю, что это увеличило бы риск до неприемлемого уровня. Чтобы преуспеть, необходимо потратить деньги и позаботиться о деталях.
Вопросы
Каковы некоторые другие причины выбора компанией Quantum метода внедрения «сразу»?
Какие факторы способствовали успешности внедрения компании Quantum?
Что вы думаете о методе тестирования, использованном Делевати?
ПРИЛОЖЕНИЕ 11-3
Quantum III:сотрудничество и конкуренция
24 июня 1996 г. подразделение прикладных систем корпорации Oracle объявило, что «несколько компаний, включая Silicon Graphics, Inc. и корпорацию Quantum, работали с Oracle Applications в течение квартала, причем обе эти компании успешно провели крупномасштабные внедрения». Кроме того, в это же время подразделение прикладных систем корпорации Oracle объявило, что «среди новых клиентов, появившихся за этот квартал компания Western Digital ...»
Вопросы
Что вы думаете по поводу выбора компанией Western Digital системы Oracle Applications? Как вы считаете, что думает компания Quantum по поводу выбора компанией Western Digital этой ERP системы?
Как вы считаете, какие возможности системы выберет для внедрения Western Digital?
12
ЖИЗНЬ ПОСЛЕ ЗАПУСКА
После завершения внедрения ERP системы забывать о ней, потому что «дело сделано», еще не время. В это время организация вступает в стабилизационный период, в течение которого она обычно переживает спад в производительности. Значит, чтобы смягчить этот отрицательный эффект, фирмам необходимо много работать. Чтобы справиться с повседневными проблемами, связанными с ERP системой, фирме необходимо организоваться, а менеджменту определить, что еще необходимо сделать, и соответствует ли результат плану внедрения системы. Менеджмент также должен решить, какая модернизация, расширение или связи могут или должны быть реализованы для ERP системы. Наконец, фирме необходимо оценить успешность проекта.
Стабилизационный период
После запуска системы начинается так называемый «стабилизационный период», продолжающийся обычно от трех до девяти месяцев. В течение этого периода, как заметил директор Benchmarking Partners: «Большинство компаний должны быть готовы к некоторому спаду в бизнесе и к тому, что им придется с ним справляться» (Koch 1999). Например, в результате проведенного недавно исследования Deloitte Consulting выяснилось, что после запуска ERP систем, каждая четвертая фирма пережила некоторый спад в деятельности.
В стабилизационный период начинают использоваться все те процессы, которые коща-то были просто планами. Новые ПО и процессы могут быть не знакомы пользователям. Соответственно, могут возникнуть проблемы с качеством и объемом работы, и, следовательно, система может не работать так, как предполагалось. Например, при обсуждении системы, которая была запущена в январе 1998 года, Коч (Koch 1999) заметил:
Доставки не осуществлялись: клиенты получали не то количество или не ту продукцию, которые они называли. У служащих отдела работы с клиентами было столько вопросов по новой системе, что первые несколько недель проектная команда потратила большую часть времени, решая возникшие у них проблемы... Только спустя пять месяцев, в мае ... компания решила проблемы со своими клиентами. Система не стабилизировалась до сентября.
Таким образом, важно, чтобы пользователи прошли соответствующее обучение в нужное время. Знания, полученные в период слишком раннего обучения, могут быть утрачены, но обучение, проведенное слишком поздно, может оказаться запоздалым.
В стабилизационный период время обработки данных и ответа сети могут не соответствовать возможностям внедренной системы, форсируя осуществление изменений пропускной способности сети и обработки данных. Например, коща ERP система была запущена в компании Cisco, обнаружилось, что основная проблема снижения производительности состояла в масштабах оборудования и его архитектуре (Cotteleer, Austin, and Nolan 1998).
Кто решает эти проблемы? В рамках организации первоначальная команда проекта может быть наращена с целью обеспечения поддержки нужд пользователей, содействия дополнительному обучению и внесения необходимых изменений в систему. Коч (Koch 1999), цитируя члена проектной команды, говорит: «В начале проекта я думала, что смогу по его завершении вернуться в свою группу...». Вместо этого во время выполнения данной работы она стала в компании сначала неофициальным помощником, а затем и консультантом со стороны SAP.
Организация,обеспечивающая поддержку ERP системы
После запуска системы команда внедрения должна остаться для поддержки пользователей. Обычно при этом организацией управляет вице-президент по информационным системам или СЮ. Деятельность по поддержке организации может включать:
обнаружение и реагирование на ошибки в системе;
ответы на вопросы пользователей (например, через справочный стол или путем обучения);
изменение системных параметров по мере изменения организации (например, по мере развития организации возникнет необходимость изменений списка поставщиков, таблицы счетов и других МОПов);
гарантирование доступности соответствующих производственных версий ПО;
управление различными возможностями ввода и вывода данных ERP системы (например, реагирование на изменение необходимости создания отчетов);
обслуживание и обновление документации и материалов обучения;
обслуживание и обновление ПО.
Кто является членами этой команды поддержки организации? Члены первоначальной проектной команды внедрения ERP могут быть важными игроками в осуществлении повседневных операций. Следовательно, важно удержать членов проектной команды, которые имеют (пользующуюся высоким спросом) сноровку, необходимую для выполнения повседневных операций в ERP системе. В целом, члены команды проекта имеют ценные знания, которые необходимо сохранить, и сделать это можно, только удержав их. Соответственно, фирмам нужно уведомить членов проектной команды по поводу их карьерных возможностей, которые позволят им использовать их знания в фирме.
Проведенное недавно исследование (Stedman 1998) выявило, что различные программные пакеты ERP требуют различных затрат на их использование. При исследовании 50 фирм, проведенном MEIA group, выяснилось, что полная стоимость использования системы за два года (в процентах от годового дохода) составила от 0,4% для ПО фирмы Lawson, до 0,67% для SAP и до 1,1% для BAAN. Конечно, экстраполяция на основании таких исследований может быть ограничена многими промежуточными факторами, такими как, например, размер фирмы. Например, система компании Lawson обычно внедряется в менее крупных фирмах, в то время как BANN имеет репутацию системы, внедряемой в основном более крупными фирмами.
Определение того,что еще нужно сделать или переделать
Установить, что должно быть сделано (или переделано) во внедренной системе, можно путем оценки преобразования данных, определения того, какие новые «узкие места» возникли в процессах с момента внедрения системы (например, в течение стабилизационного периода) и оценки достаточности обучения и документации.
Преобразование данных
Важной задачей, которую требуется решить при переходе от традиционной системы к ERP системе, является задача преобразования данных. При внедрении старые данные необходимо преобразовать в соответствующий формат и упорядочить. Потребность в из-
менении данных имеет ряд источников, таких как существование новых полей и разработка новых МОПов (списков поставщиков, таблиц счетов ит. д.).
Во многих случаях качество преобразования данных (и вытекающие отсюда проблемы) может быть оценено только со временем. Накопленные данные необходимо исследовать на «смысл». Например, может оказаться, что происходит накопление запасов, падение сборов, и начинают происходить простои в работе. Но эти изменения на самом деле могут говорить о проблемах, возникающих из-за неадекватного преобразования данных: неверных номеров подразделений, поставщиков или инвентарных номеров.
Решение потенциальных проблем, связанных с преобразованием данных, обычно требует ряда действий, включая следующие. Во- первых, где можно, следует привести в соответствие данные в их источниках для традиционной системы и ERP системы, поставив такие вопросы, как: Совпадают ли инвентарные номера? Если нет, то почему? Совпадают ли номера товаров? Если нет, то почему? Совпадают ли номера поставщиков (клиентов и т. д.)? Если нет, то почему? Во- вторых, нужно осуществить отображение данных из одной БД в другую, чтобы убедиться, что включены все данные. Отображение данных может выявить новые и пропущенные номера как товаров, так и поставщиков, и клиентов. Запасы должны быть эквивалентны. Без этих мероприятий нет гарантии того, что при преобразовании данных не были перепутаны какие-то их разновидности или что все данные учтены.
«Узкие места» процессов
Независимо от то「о, сколько усилий было затрачено или насколько хорошо было выполнено внедрение и планирование, в процессах и операциях все же могут остаться «узкие места», не приносящие преимуществ. Таким образом, фирмы должны систематически идентифицировать такие «узкие места» и действия.
1де могут возникнуть «узкие места»? Во-первых, места их возникновения могут быть разными для разных фирм. Во-вторых, они могут быть следствием межфункциональной природы процессов ERP систем, особенно когда различные подразделения имеют различные ресурсы. В-третьих, в условиях, когда сбор данных был перенесен с места учета к месту их создания, «узкие места» процессов могут возникнуть из-за изменений в самом вводе данных. В-четвертых, производительность системы могут ухудшить связи с традиционными системами и процессами.
Как определить «узкие места»? Один из подходов — прислушаться к клиентам и партнерам. На что они жалуются? Установить причину этого недовольства. К сожалению, недовольство возникнет не сразу. Другой подход ——сидеть и ждать, пока вопросы и запросы ресурсов не завалят справочный стол. Этот подход также может оказаться слишком запаздывающим.
Для обнаружения «узких мест» можно использовать два других подхода: внутренний анализ данных ERP системы и организационный анализ. Внутренний анализ ERP системы базируется на исследовании ее данных. Для выявления возникающих и повторяющихся проблем могут быть проанализированы сообщения о простоях и операционные данные. С другой стороны, до того, как они превратятся в главные проблемы, некоторые затруднения могут быть выявлены из бесед с теми, кто использует систему.
Документация и обучение
Для работы с системой требуются знания о ней и о процессах. Таким образом, до запуска системы необходимо провести соответствующее обучение и получить документацию. Это, похоже, проблемная область, так как практически все организации или недооценивают необходимость обучения, или не выделяют на него достаточных средств. До запуска системы адекватность обучения и документации реально оценены быть не могут. Но когда система начинает работать, начинается рассмотрение изменений в документации и дополнительное обучение, и ресурсы на это находятся.
Сравнение плана и реальности
Другой источник информации о том, что еще необходимо сделать, —это сравнение плана и реальности. Для ERP систем это сравнение имеет, по крайней мере, три аспекта: проектирование и внедрение системы, запланированное и фактическое использование, ожидаемые и действительные возможности систем. Основная природа этого сравнения приравнивает сопоставительный анализ к аудиту, осуществляемый, возможно, другим персоналом или даже сторонними организациями.
Эти сравнения критически важны. Если отмечены отличия плана от факта для любого из аспектов, успешность проекта может быть поставлена под сомнение. Например, решение о внедрении ERP системы, возможно, было принято в предположении об изменениях в
соответствии с лучшими практиками, что, как ожидалось, должно привести к организационным усовершенствованиям и повышению эффективности работы организации. Однако если ERP система была внедрена не так, как планировалось, то эти преимущества могут быть не достигнуты. Таким образом, основная причина (или причины) выбора ERP системы при внедрении, возможно, не была принята во внимание.
Почему могут появиться отличия? Возможно, наибольший источник проблем — компромиссы при внедрении.
Компромиссы при внедрении
Компромиссы при внедрении — это отклонения внедрения от запланированного в основном в целях экономии времени или денег Зачастую в стремлении видеть систему установленной идут на компромиссы. После того, как система внедрена, важно выяснить, что необходимо сделать или переделать в результате этих компромиссов. Например, как заметил старший менеджер по системам корпоративного учета Federal Express: «Во время реализации проекта существуют проблемы со временем или возможностями, которые заставляют вас говорить: «Мы сделаем это позже» (Koch 1999).
Каковы последствия компромиссов при внедрении? Установка ERP системы в этом случае, конечно, позволяет сэкономить время или деньги по сравнению с возможными издержками при отсутствии компромиссов. Однако, так как внедрение не было полным, система и процессы не будут функционировать в полной мере так, как предполагалось. Таким образом, компромиссы при внедрении повлияют на оценку. В некоторых случаях они могут, в конечном итоге, привести к компромиссам в обязательствах, как, например, когда переход к ERP системе осуществлялся в целях изменения ключевых процессов или для привнесения ключевых изменений, а именно здесь пошли на компромисс.
Один из компромиссов при внедрении — это временное принесение в жертву безопасности. Например, парольная защита может быть сначала установлена на групповом, а не на индивидуальном уровне. Другой частой областью компромиссов при внедрении является ввод/вывод данных. Например, после внедрения ERP системы компанией Geneva Steel было обнаружено, что не выполняются требования пользователей по созданию отчетов. Для соответствия этим требованиям было установлено хранилище данных, которое использовалось для создания отчетов в соответствии с запросами пользователей. Это показывает,
как важно повторно возвращаться к компромиссам, сделанным при внедрении, чтобы удостовериться, что любые нерешенные проблемы решены должным образом.
Как фирмам следует идентифицировать компромиссы внедрения? Есть, по крайней мере, три метода. Во-первых, чтобы убедиться, что все было сделано, можно провести сравнение внедрения и плана. Во-вторых, фирма может установить специальные линии связи, чтобы получать сообщения своих служащих о проблемах, возникающих у них с системой. В-третьих, фирмы часто привлекают консультантов для рассмотрения внедрения с целью обнаружения таких компромиссов, особенно в таких сферах, как безопасность.
Проектирование и внедрение системы
Проект системы не всегда соответствует тому, что получается в результате внедрения. В конечном итоге внедренные процессы и МОПы могут не соответствовать первоначально запланированным. Чтобы найти отличия, запланированное внедрение нужно сравнить с фактическим. Когда отличия найдены, они должны быть исследованы для того, чтобы убедиться в их санкционированности.
Сравнение запланированного
и фактического использования
То, как используется система, может не соответствовать тому, что было запланировано. Для выяснения того, как система используется в действительности, может быть проведен системный аудит. Например, отчеты, сделанные доступными для одних пользователей, могут оказаться доступными и для других, и, возможно, стоит проверить, должны ли получать данные отчеты эти, последние пользователи.
Сравнение функционирования системы:
ожидания и реальность
Время после запуска — это время, когда фирма получает от топ- менеджмента подтверждение действенности системы. На этом этапе образ ERP системы достаточно реален для сравнения с тем, что ожидалось. Например, как мы видели в случае с компанией Geneva Steel, предполагалось, что внедрение SAP приведет к далеко идущим изменениям в организации. Сравнение ключевых аспектов образа системы и реальности необходимы для того, чтобы убедиться в том, что система работает так, как предполагалось.
Организация связей, модернизация и расширение
После стабилизации ресурсы, направленные на внедрение, могут быть использованы для содействия организации связей с другими системами и для определенного расширения ERP системы. В течение этого процесса должны быть определены приоритеты различных связей, обновлений и расширений (а) для извлечения максимальной пользы из затрат и (б) для идентификации соответствия приоритетов общему видению фирмы.
Модернизация
В некоторых случаях для внедрения дополнительных характеристик должен быть осуществлен переход на другие версии системы. Например, фирма АВВ поставила в известность каждую из тысячи своих компаний о том, что они должны внедрить функциональностоимостной анализ — возможность, которую ABB Industries решила реализовать с помощью SAR Однако после внедрения версии 3.0 системы R/3 обнаружилось, что для полного внедрения этого вида анализа требуется более поздняя версия ERP системы. То есть, возможность внедрения фирмой необходимой характеристики ——функционально-стоимостного анализа ——зависела от внедрения новой версии SAP.
Связи
Хотя ERP системы спроектированы для функционирования, не зависимого от других систем, они, тем не менее, могут быть связаны с множеством других систем. Чтобы гарантировать, что ERP система будет запущена в запланированное время, эти связи иногда не реализуются до даты «начала жизни» системы. Такие связи могут быть установлены после внедрения.
Расширения (новые характеристики и функции)
Во многих фирмах системы планирования ресурсов предприятий стали «информационной магистралью», предоставляя возможность обработки данных практически для всех операций фирмы. ERP системы расширялись в различных направлениях. Например, производители этих систем стали предоставлять возможности поддержки интеграции цепочек поставок и автоматизации деятельности продавцов. В некоторых случаях об этих расширениях знали при выборе ПО, и они, возможно, повлияли на окончательный выбор. В других случаях могут появляться новые расширения ПО ERP сис-
тем, к которым фирме нужно вернуться и рассмотреть с целью принятия решения о том, должны ли эти возможности быть приняты во внимание и внедрены.
Оценка успеха
По окончании стаб14nl^замоннопэ периода фирма может начать процесс оценки успешности проекта. Это требует определения того, когда должна быть выполнена такая оценка и как именно должна быть оценена успешность, — например, с помощью анализа затраты-выгоды, некоего анализа, основанного на критериях, использованных при решении о внедрении ERP системы, или при помощи метода Balanced Scorecard (BSC)
Таблица 12Д. Реальные и предполагаемые факторы проекта
Каковы были реальные выгоды в процентах от ожидаемых: Продолжительность СтоимостьВыгоды
<50%0,050 %-100%25,0100%-125%27,5125%-150%25,0150% 175%3,0175%-200%16,5>200%3,0<50%0,050 %-100%25,0100%-125%27,5125%-150%25,0150% 175%3,0175%-200%16,5>200%3,00 5 0 5 0 5 061343м&2&0 5 0 5 0 5 061343м&2&Q Q 5 5 о о ок^- ^ &14а а аQ Q 5 5 о о ок^- ^ &14а а а
<50%
0,0
50 %-100%
25,0
100%-125%
27,5
125%-150%
25,0
150% 175%
3,0
175%-200%
16,5
>200%
3,0
<50%
0,0
50 %-100%
25,0
100%-125%
27,5
125%-150%
25,0
150% 175%
3,0
175%-200%
16,5
>200%
3,0
0 5 0 5 0 5 061343м&2&
0 5 0 5 0 5 061343м&2&
Q Q 5 5 о о ок^- ^ &14а а а
Q Q 5 5 о о ок^- ^ &14а а а
Примечание: Выгоды являются средними процентными соотношения
ми данных 1998 и 1999 гг., рассмотренных в (Austin and Cotteleer 1999).
В некоторых случаях из-за округления сумма чисел в некоторых колонках не равна 100%.
Выбор времени
Выбор времени является важным вопросом при оценке новой системы. Выгоды редко могут быть полностью достигнуты немедленно после внедрения, либо будет недостаточно информации. Таким образом, необходимо запланировать оценку на то время, когда выгоды могут быть достигнуты и измерены. Соответственно, фирмы обычно оценивают внедрение ERP системы в течение первого или второго года после ее запуска. К этому времени будут устранены
многие системные ошибки. Кроме того, система за год создаст данные, которые могут быть использованы в качестве основы для оценки —например, улучшилось ли движение запасов?
Определение продолжительностиг затрат и выгод
Проектный менеджмент требует мониторинга продолжительности проекта, затрат и выгод от внедрения (например, бизнес-преиму- ществ) ERP системы. Было множество сообщений о проблемах со своевременностью и «рентабельностью» внедрения ERP систем. Проведенное недавно исследование (Austin and Cotteleer 1999), результаты которого представлены в таблице 12.1, выявило, что выгоды от реализации проектов внедрения ERP часто не оправдывали ожиданий, при том, что затраты часто превышали ожидаемые. Вероятно, это можно объяснить тем, что с целью продажи систем топ-менеджменту затраты могли систематически преуменьшаться, а потенциальные результаты переоцениваться.
Хотя продолжительность проекта была иногда меньше, чем предполагалось, чаще она была больше предполагаемой, причем в некоторых случаях больше почти вдвое. Таким образом, не удивительно, что внедрения ERP систем имеют репутацию превышающих бюджет и запланированное время (см,5 например, March and Garvin 1996).
Однако, возможно, самый интересный результат исследования —— это то, что только 44% фирм формально отследили полученные выгоды. Кроме плохого проектного менеджмента, это можно объяснить и другими причинами. Во-первых, общеизвестно, что выгоды определить сложнее, чем затраты, так как часто они менее материальны. Во-вторых, может не существовать способов их определения, особенно когда проект был обоснован технологическими, стратегическими или конкурентными доводами, и, следовательно, конкретные выгоды не могут быть выделены . В-третьих, фирмы могут рассматривать внедрение как неокупаемое капиталовложение и, следовательно, не видят пользы от оценки выгод.
Резоны* использованные при выборе
Другой подход к оценке ——определение соответствия системы критериям, изначально установленным для нее. В этом случае для оценки успешности могут быть использованы резоны, использованные при выборе (рассмотренные ранее). Однако одни резоны выбора будут больше способствовать процессу этой оценки, чем другие.
Технологические основания для выбора, такие как необходимость приобрести ПО, обеспечивающее работу в модели клиент-
сервер, решить «Проблему 2000-го года» или ответить на вызов со стороны конкурентов, не обеспечивают определенность оценки. Как только принято решение о внедрении ERP системы, и, таким образом, вопросы «Проблемы 2000-го года» и ПО, работающего в среде клиент-сервер, решены, оценить мало что можно. Основание легко «ответить на вызовы конкурентов» может быть слишком аморфным, и здесь достаточно просто решить установить ту же ERP систему, что и конкуренты. Это может стать важным для сбора более детальных метрик производительности, таких как, например, что значит «соответствовать» конкуренции, чтобы зафиксировать в проекте большие специфику и обратную связь.
Стратегические резоны и основания со стороны бизнес-процессов могут способствовать более определенной оценке. Например, основанием могло послужить улучшение управления запасами. С улучшением управления запасами могут быть ассоциированы конкретные измерения сырья, полуфабрикатов и готовых товаров. Уровни запасов, запасов в процентах к продажам или движение запасов могут быть использованы как конкретные критерии оценки улучшений. Приведем другой пример: резоном послужило улучшение перевозок и материально-технического снабжения. С улучшением перевозок и материально-технического снабжения могут быть связаны конкретные показатели затрат на содержание складов и на перевозки. Например, предполагаемое сокращение затрат на содержание складов благодаря внедрению ERP системы может быть оценено в процентах от продаж.
Конкретные показатели позволяют детализировать исследование в процессе оценки. Если измерения выявляют меньшие улучшения, чем предполагалось, фирмам необходимо выяснить причину и определить, возможны ли дальнейшие улучшения. Фирма также может решить, как настроить ERP систему, чтобы ее внедрение позволило достигнуть конкретных целей.
Независимые показателиили взвешенный набор показателей
При любой оценке внедрения ERP систем необходимо определить, использовать для оценки проекта независимые показатели или набор показателей. Если используются независимые показатели, и все они достигнуты, то результаты оценки понятны. Однако если одна или несколько целей не достигнуты, то возникает некоторый вопрос относительно результатов оценки. Напри-
мер, означает ли, что если один показатель ниже нормы, то внедрение не было успешным?
Проблемы оценки возникают и при использовании множества таких показателей, как «взвешенный набор» показателей. В этом случае для определения общей эффективности необходимо установить удельные веса индивидуальным статьям. Другой метод оценки — система сбалансированных показателей.
Система сбалансированных показателей
Данный метод оценки функционирования организаций был опубликован в работах Каплана и Нортона (Kaplan and Norton 1992) и Каплана и Аткинсона (Kaplan and Atkinson 1998). Система сбалансированных показателей отражает различные цели фирмы с различных точек зрения, таких как финансы, клиенты, обучение и рост, а также внутренние бизнес-процессы. В процессе оценки используются различные показатели, а не один показатель или один тип показателей.
Метод использования различных точек зрения и множества показателей может быть распространен на оценку внедрения ERP систем. В системе сбалансированных показателей для ERP системы могло бы быть использовано каждое из четырех основных бизнес-ос- нований (технология, бизнес-процесс, стратегия и конкуренция), использованных при принятии решения о внедрении ERP системы, и таким образом определен набор перспектив и показателей, которые будут зависеть от конкретной компании и ее резонов внедрения ERP системы.
Бюджет на период после запуска системы
Наконец, для осуществления всех описанных в данной главе мероприятий необходим бюджет и соответствующий план для поддержки завершения проекта. Без бюджета не будет ни людей, ни прогресса. Полный проектный менеджмент означает управление на протяжении всего жизненного цикла проекта, включая период после запуска системы. В большом числе отчетов фирм зафиксировано, что у многих из них к началу стабилизационного периода не оставалось средств. Другие отчеты указали на то, что фирмы не имели достаточных бюджетов для того, чтобы члены проектной команды остались на этот период, и в результате они занялись другими проектами внедрения ERP.
Резюме
После запуска ERP системы предстоит еще многое сделать. Команда внедрения должна провести фирму через стабилизационный период. Кроме того, необходима организация для повседневного поддержания работы системы. После запуска системы фирма должна определить, что необходимо сделать и переделать. Например, преобразование данных, компромиссы, допущенные при внедрении, «узкие места» в процессах и документация — все это следует оценить, чтобы гарантировать, что все соответствует нуждам. Для определения пределов компромиссов при внедрении фирмам необходимо сравнить свои планы с реальными результатами. Они должны также рассмотреть, какую модернизацию системы им следует осуществить, какие связи с традиционными системами необходимо реализовать, и должны ли быть сделаны какие-нибудь расширения ERP системы, и если да, то какие.
Фирмам необходимо оценить успешность внедрения. Однако одно исследование показало, что анализ выгод осуществляют только 44% фирм. Отсутствие анализа выгод может быть следствием плохого проектного менеджмента, трудности оценки результатов, оснований, использованных для выбора или оценки внедрения ERP системы или рассмотрения проекта как неокупаемого капиталобложения. В тех случаях, когда выгоды анализируются, может быть использован продолжительный анализ затрат и выгод. Могут также быть использованы другие средства оценки, базирующиеся, возможно, на резонах, использованных при принятии решения о внедрении ERP системы, или какие-то иные. В любом случае, так как выгоды требуют времени для их проявления и возможности измерения, оценку следует начинать не раньше, чем через год после запуска системы.
Наконец, многие фирмы не выделяют достаточных бюджетов на рассмотренные в данной главе задачи, которые необходимо реализовать после внедрения системы. Для проведения проею-ного менеджмента в течение всего ее жизненного цикла необходим адекватный бюджет, чтобы гарантировать наличие ресурсов в течение реализации всего проекта.
Литература
Austin, R., and Cotteleer, М. (1999). «Current Issues in IT: Enterprise Resource Planning». Unpublished presentation, October.
Cotteleer, М., Austin, R., and Nolan, R. (1998). «Cisco Systems, Inc.: Implementing ERP» Report no. 9-699-022, Harvard Business School, Cambridge, MA.
Kaplan, R., and Atkinson, A. (1998). Advanced Management Accounting.
Englewood Cliffs, NJ: Prentice-Hall.
Kaplan, FL, and Norton, D. (1992). «The Balanced Scorecard: Measures That Drive Performance». Harvard Business Review, January/February.
Koch, C. (1999). «The Most Important learn in History». CIO Magazine, October 15.
March, A., and Garvin, D. (1996). «SAP America». Report no. 9-397-057, Harvard Business School, Cambridge, MA.
Stedman, C. (1998). «ERP User Interfaces Drive Workers Nuts». Computerworld, November 2, pp. 1,24.
ПРИЛОЖЕНИЕ 12-1
Изучение случая компании XVZ*Как следует оценить ERP-проект?
Наша фирма выработала и распространила следующие показатели. Эти показатели были выдвинуты как желаемые примерно через год после запуска системы.
Запасы
Сокращение имеющегося в наличии сырья на срок менее 20 дней.
Сокращение продукции в незавершенном производстве на 40%.
Повышение оборачиваемости готовых товаров с9до12 раз в год.
Общее администрирование
Публикация финансовых материалов в течение 6 рабочих дней (в настоящее время 24 дня).
Повышение уровня обслуживания клиентов до 99%, а своевременности доставки до 90% (в настоящее время 97% и 70%, соответственно).
Повышение эффективности производства, продаж, финансов, закупок, техники и информационных систем на 10%.
Подразделение А
Повышение валовой прибыли на 6% от продаж.
Подразделение 6
Повышение валовой прибыли на 2% от продаж.
Я обеспокоен тем, что мне не ясно, является это показателями или целями. Кроме того, внедрение не добавляет функциональности, которая уже номинально не присутствовала бы. Поэтому буду признателен вам за высказанные замечания по следующим вопросам.
Что вы думаете по поводу этих метрик?
Являются ли они показателями или целями?
Если это цели, подходят ли они для проекта внедрения ERP системы?
Если это показатели, позволяют ли они оценить факторы, непосредственно относящиеся к внедрению?
Представляют ли эти показатели (цели) по отдельности или все вместе разумные ожидания команды менеджмента относительно их ERP проекта? Если нет, то 侬кие показатели или цели будут надлежащими?
ПРИЛОЖЕНИЕ 12-2
Список контрольных вопросов компании Deloitte Consultingдля периода после внедрения ERP системы"
Проекты внедрения ERP систем более успешны, если имеется конкретный план действий на период после запуска системы. Задайте себе эти вопросы относительно планов после внедрения, чтобы понять, готовы ли вы и ваша команда. Если на какой-то из них ваш ответ будет отрицательным, сделайте шаги, чтобы как можно скорее перевести ответ на него из НЕТ в ДА.
Основы
У вас есть план действий после внедрения?
“е刀и получения преимуществ
• Есть ли у вас перечень бизнес-выгод и возможностей от использования ERP системы в бизнес-планах конкретных главных управляющих (CEO, CFO и т. д.)?
* Данный список контрольных вопросов представлен в Koch, С. (1999). «The Most Important Team in History.» (C/O Magazine, October 15), где он пр/п/сь旧ается компании Deloite Consulting (прим, автора).
Донесли ли вы предполагаемые бизнес-выгоды от внедрения ERP системы до остальной части вашей организации?
Проектные команды
Была ли сохранена проектная команда?
Разработала ли организация план удержания служащих с необходимыми навыками?
Известно ли членам проектной команды об имеющихся у них карьерных возможностях в компании?
Бизнес-показатели
Существуют ли бизнес-показатели для оценки намеченных результатов проекта в сравнении с фактически достигнутыми.
Были ли назначены ответственные за процесс отслеживания каждого из показателей?
Проектный менеджмент
Существуют ли у вас программы, помогающие людям справиться с изменениями их роли и со стрессом, связанным с этими изменениями?
Был ли организован экспертный центр или создана организация для поддержки внедрения ERP системы для ответов на вопросы пользователей, вопросы обслуживания и модернизации?
Экспертиза процессов
Стал ли менеджмент больше ориентироваться на процессы, чем это было до проекта внедрения?
Существует ли программа поощрения служащих, пользующихся системой?
Рассматриваются и одобряются ли запросы на создание новых отчетов одним из ответственных за процесс (чтобы избежать «засорения» системы)?
Фундамент ERP системы
Существуют ли планы расширения функциональных возможностей ERP системы?
Обучение
Основано ли обучение пользователей на их специальности (кроме простого обучения использованию ПО)?
13
ОБУЧЕНИЕ
Одним из наиболее важных аспектов внедрения ERP системы является обучение. Как заметил СЮ компании Brother Industries: «Самая распространенная ошибка — недооценка времени и затрат на обучение конечных пользователей» (Fortune 1998 с. 151). Внедрение не будет успешным, если ПО работает отлично, а служащие не знают, как им пользоваться. Несмотря на важность обучения работы с ERP системой, исследование 150 примеров, проведенное компанией Benchmarking Partners, показало, что в 43% случаев значимость обучения была самой большой неожиданностью, с которой они столкнулись (Stedman 1998b).
Однако обучение касается не только пользователей — необходимо принять во внимание также обучение тех, кто осуществляет внедрение. Более того, обучение — это не просто один из этапов жизненного цикла непосредственно перед или непосредственно после внедрения. Обучение идет на протяжении всего жизненного цикла. Поэтому обсуждению обучения мы посвящаем отдельную главу.
Часто задаваемые вопросы об обучении пользователей
Как должно быть рассчитано обучение пользователей?
В каком объеме должно проводиться обучение пользователей?
Как компенсировать временные затраты на обучение?
Когда должно проводиться обучение?
Как сделать так, чтобы служащие проходили обучение?
Сколько должно стоить обучение?
Чему лучше обучать ——информационной технологии или бизнесу?
Какие материалы использовать для поддержки — сценарные или общие?
Как структурировать обучение?
Возможно ли более быстрое обучение?
Как должно быть рассчитано обучение пользователей?
Знания, полученные в результате обучения, проводимого задолго до запуска системы, будут утрачены. Обучение, начатое слишком поздно, не будет завершено вовремя, и стабилизационный период может затянуться. Чтобы провести обучение в период до запуска си-
стемы, фирма должна учесть, сколько времени пройдет до запуска и сколько времени потребуется на обучение пользователей. Например, компания Purina Mills начала обучение пользователей за четыре месяца до запуска SAP R/3 (Stedman 1998а).
В каком объеме должно проводиться обучение пользователей?
Объем необходимого обучения зависит от конкретного модуля, использованию которого обучаются служащие. Как заметил Стедман (Stedman 1998а), в некоторых случаях для того, чтобы пользователи смогли уверенно и профессионально работать с ERP системой, может потребоваться до шести месяцев. Стедман (Stedman 1998b) сообщает, что перед запуском системы SAP R/3 в компании Purina Mills группа финансистов обучалась по семь часов ежедневно в течение месяца.
Как компенсировать временные затраты на обучение?
Время, потраченное на обучение, — это время, «украденное» у повседневной работы. Были найдены различные решения того, как освободить достаточно времени на обучение работников. В компании Purina Mills (Stedman 1998b) менеджеры добавили дополнительное время для проведения обучения к рабочему. В корпорации Microsoft (Bashein, Markus, and Finley 1997, c. 71) было добавлено дополнительное время, и предполагалось, что пользователи будут выполнять и ту, и другую работу. Однако некоторые фирмы на период обучения своих специалистов привлекали временных служащих.
Когда должно проводиться обучение?
Время, отведенное на обучение, показывает, насколько оно важно для внедрения. Обучение, запланированное на рабочее время, говорит о его важности, в то время как обучение, запланированное на внерабочее время, дает основание полагать, что оно не столь важно, как повседневные обязанности.
Например, СЮ одного из предприятий отметил, что корпорация запланировала запросить 80 часов на обучение служащих. Он не видел необходимости тратить на обучение столько времени и считал, что оно не может проводиться в рабочее время. В результате он запланировал обучение служащих на выходные дни в течение трех недель подряд. По поводу такой стратегии возникают, по крайней мере, два вопроса.
Как служащие поймут относительную важность обуче- ния? Служащие, возможно, воспримут обучение как что-то менее
важное, чем их повседневная работа. В результате они будут уделять ему меньше внимания, чем необходимо.
Многому ли, по вашему мнению, научатся служащие в результате такого обучения по выходным? Служащие в результате такого обучения, возможно, не научатся работать столь же хорошо, сколь они могли бы это сделать, если бы обучались в рабочее время. Многие служащие, скорее всего, будут пропускать занятия, а даже одно пропущенное занятие может помешать пониманию материала остальных занятий.
Как сделать ma/с чтобы служащие проходили обучение?
Наибольшее внимание зачастую привлекает самая неотложная деятельность ——в ущерб другой деятельности, менее актуальной на текущий момент. Это означает, что работе на производстве обычно уделяют больше внимания, чем обучению, и таким образом, если фирмы не позаботятся о том, чтобы пользователи относились к нему серьезно, обучение пользователей использованию ERP системы может уйти на второй план. В результате фирмы вводят различные виды наказания и поощрения. Например, во время внедрения корпорацией Microsoft системы SAP обучение считалось обязательным для конкретных ключевых пользователей. Было сделано предупреждение, что учетные записи пользователей информационной системы компаниии, не посещающих занятия, будут удалены. Как сказал главный бухгалтер: «Нам пришлось удалить только около 20 записей» (Bashein и др. 1997, с. 71).
Таблица 13,1. Реальные и предполагаемые расходына обучение пользователей
Насколько близки были затраты на обучение пользователей и другие расходы на ERP систему
вашей изначальной оценке?
Более чем на 50% выше ожидаемых8%
От 10% до 50% выше ожидаемых26%
До 10% выше ожидаемых58%
Более чем на 10% ниже ожидаемых6%
Не знаю2%
Примечание: базируется на материале исследования 50 крупных американских компаний, проведенного в августе 1998 г: Источник: Forrester Research, Inc. (Cambridge, Massachusetts).
Сколько должно стоить обучение?
Стоимость обучения будет варьироваться в зависимости от конкретного проекта. Однако, как сказал Стедман (Stedman 1998а), бюджет обучения может составлять 10% или более того от общего бюд-
жета проекта. Во многих фирмах происходит перерасход средств на обучение. Проведенное недавно исследование 50 фирм (см. таблицу 13.1) показало, что у 17 фирм перерасход средств на обучение составил 10% или более от начального бюджета.
Чему обучать — информационной технологии или бизнесу?
Обучение пользователей работе с ERP системой ——это смесь из технологии, процессов и специальных знаний, чтобы обеспечить контекст для системы. В противном случае обучение может превратиться в «ERP-надувательство», когда пользователям говорят: «Сделайте то, затем это...» Например, по поводу внедрения SAP компанией Microsoft ее главный бухгалтер сказал: «Я 20 раз проводил шестичасовой курс обучения вводу учетных данных в SAR Это был такой же курс по обучению бухгалтерскому учету, как и по обучению пользованию системными средствами» (Bashein и др. 1997, с. 71).
С другой стороны, обучение пользователей может стать слишком общим, не нацеленным на определенное ПО. Например, когда был осуществлен переход системы SAP R/3 с версии 2.2 на версию 3.0, была предпринята попытка привести обучение в соответствие с функциональными возможностями ПО, но новые функциональные возможности понятны не были. Поэтому, как заметила Херт (Hirt 1999, с. 13) по поводу внедрения SAP компанией Siemens, один из его участников сказал: «Предложенное обучение было «основами» — другими словами, бесполезным».
Какие материалы использовать для поддержки — сценарные или общие?
Существуют, по крайней мере, два вида справочных материалов: общие и сценарные. Общий справочный материал обычно не зависит от контекста ——в нем перечислены возможности и даны определения терминам, наподобие Help-документации.
Siemens Power Company создала сценарные руководства для пользователей, предназначенные для проведения конечного пользователя шаг за шагом через всю операцию (Hirt 1999). Эти руководства доступны пользователям в локальной сети. Такой подход имеет некоторые преимущества. Во-первых, в такого рода руководствах пользователи могут найти ответы на часто задаваемые вопросы. Во- вторых, они также служат документацией по использованию системы. И, наконец, такого рода материалы основаны на контексте, предоставляя пользователям не только информацию, но и контекст, в котором она применяется.
Однако, как заметил один из конечных пользователей компании Siemens Power, у сценарных материалов существуют некоторые недостатки:
Мы можем следовать предоставленным нам сценариям, но что, если случится что-то такое, чего в этих сценариях нет? Мы понимаем, что не знаем, что делать. Приходится действовать наугад... Возникает паническое чувство, так как мы не знаем, где найти нужную информацию (Hirt 1999).
Как структурировать обучение?
Обычно большинство про「рамм обучения исходят из анализа того, что имеет конкретная компания, и что нужно сделать. Почти все обучение использованию ERP систем ориентировано на проведение его в аудитории. Однако, среди других используемых форм обучения —обучение через Интернет, компьютерная форма обучения и самообучение.
Основываясь на неформальных беседах с консультантами, можно сказать, что один из общепринятых методов подразумевает назначение члена (или группы членов) организации-клиента «суперпользователем», который впоследствии сможет обучать других. Обучение «супер-пользователей» имеет некоторые преимущества. Во- первых, этот метод обеспечивает поддержку пользователей, так как обучающими являются те, кого эти пользователи знают. Во-вторых, существование «супер-пользователей» показывает другим («обычным») пользователям, что обучение работе с системой важно. В-третьих, развивающийся «супер-пользователь» раскрывает важное понимание системы на пользовательском уровне.
Возможно ли более быстрое обучение?
Так как проекты внедрения ERP систем часто отстают от графика, фирмы могут попытаться ускорить обучение. Например, в проекте внедрения SAP компанией Microsoft: «Проектная команда переделала обучение SAP и сделала его коротким и быстрым» (Bashein и др. 1997, с. 71). Способность фирм ускорить обучение зависит от нужд фирмы, персонала и предшествующего обучения. Иногда один персонал быстро обучаем или имеет больше времени на обучение, чем другой. Обучение будет проходить быстрее или медленнее в зависимости от похожести новой системы на старую. Однако попытка ускорить обучение несет в себе потенциальную опасность и может привести к провалу проекта.
Обучение персонала^ осуществляющего внедрение
Пользователи ERP системы — не единственные, кто должен быть обучен работе с ней. Кроме них, должны пройти соответствующее обучение также служащие фирмы, ответственные за внедрение.
Специфичность обучения работе с конкретной версией ERP системы может повлиять на быстроту и эффективность внедрения. Неадекватное обучение может негативно отразиться на внедрении. Например, незнание возможностей системы может привести к ненужным изменениям, замедляющим внедрение и увеличивающим расходы (см. внедрение ERP компанией Dow Corning, описанное Россом (Ross 1998).
В начале 1995 匚 топ-менеджмент компании Dow Corning решил внедрить SAP R/3 в рамках программы реинжиниринга фирмы. В июне 1995 匚 в качестве членов команды внедрения были выбраны 40 руководящих сотрудников фирмы. Так как компания планировала не привлекать сторонних служащих для поддержки SAP, было решено не пользоваться услугами консультантов. Таким образом, было необходимо хорошо обучить членов проектной команды. В сентябре 1995 二 это обучение началось. К сожалению, как сказал Росс (Ross 1998, с. 14), хотя «большинство членов команды в сентябре 1995 匚 прошли основательную подготовку, осуществляемую SAP, большая ее часть была связана с системой R/2 и не могла быть непосредственно применена к системе R/З». В результате после обучения члены команды все еще не знали, как проектировать процессы и конфигурировать ПО. Возможно, в результате этого неадекватного обучения первое экспериментальное внедрение было отложено и завершено только в марте 1997 匚
Отсутствие адекватной подготовки также повлияло на количество и качество изменений, реализованных в ERP системе в рамках внедрения. Например, как сказал один из членов проектной команды:
В бухгалтерии мы решили оценить все наши операции одним способом для менеджмента, и сделать это другим способом для удовлетворения требований, установленных законом , но SAP с ее знаниями, не проработала эти требования. Поэтому нам пришлось программировать самим. Сейчас, когда мы полностью изучили наш
* Имеются в виду решение задач управления компанией и подготовки информации дл налоговых и иных контролирующих органов (прим. науч, редактора).
процесс и поняли, что нам действительно нужно делать, и чем SAP может нам в действительности помочь, наш процесс будет намного лучше, и нам не придется использовать изменения, которые мы сделали в SAP. (Ross 1998, с. 14)
Резюме
Обучение важно в течение всего жизненного цикла системы. В данной главе мы остановились на вопросах обучения пользователей и персонала, осуществляющего внедрение. Были рассмотрены некоторые часто задаваемые вопросы, касающиеся обучения пользователей. Кроме того, был рассмотрен пример для иллюстрации некоторых проблем, возникающих из-за неадекватного обучения персонала, осуществляющего внедрение.
Литература
Bashein, В., Markus, L., And Finley, J. (1997). Safety Nets: Secrets of Effective Information Technology Controls. Morristown, NJ: Financial Executives Research Foundation.
Fortune (1998). «Managing ERP». February 2, pp. 150-1.
Hirt, S. (1999). «Siemens Power Company: Surviving R/З». Unpublished case study*
Ross, J. (1998). «Dow Corning Corporation». Paper presented at the International Conference on Information Systems (Helsinki), December.
Stedman, C. (1998a). «ERP User Interfaces Drive Workers Nuts». Computerworld, November 2, pp. 1,24.
Stedman, C. (1998b). «Surveys Show a Training Surprise». Computerworld, November 2, p. 24.
Часть четвертая
ЭЛЕКТРОННАЯ КОММЕРЦИЯ
И РИСКИ
14
ERP СИСТЕМЫ И ЭЛЕКТРОННАЯ КОММЕРЦИЯ
Электронная коммерция является важным аспектом ведения бизнеса. Для многих фирм она неотделима от обычной коммерции ——связь между ними становится все более тесной. Для компании Cisco число заказов, сделанных через Интернет, в 1999 г. возросло и составило примерно 85%, в то время как в 1996 г. оно составляло менее 10%. В результате этих впечатляющих изменений произошли не менее значительные изменения в том, как бизнес использует электронную коммерцию. Такие фирмы, как Cisco, используют ее для упрощения бизнес-процессов и улучшения работы с клиентами (Riggs 1999).
Электронная коммерция возникла примерно в то же время, что и ERP системы. Кроме того, оба эти явления в значительной степени зависят от изменений в процессах приспособления к новой технологии, что приводит к следующему вопросу： «Каковы взаимоотношения между этими двумя явлениями?» Этот вопрос рассматривается в данной главе, при этом сначала ERP системы
определяются как один из основных строительных блоков электронной коммерции, а затем устанавливается роль ERP систем для каждой из основных операций электронной коммерции: рассмотрение заказов, конфигурирование заказов, размещение заказов, запасы, управляемые производителями, производство на заказ и «стыковка при доставке».
Строительные блоки электронной коммерции
Каковы некоторые строительные блоки электронной коммерции? ERP системы предоставляют хранилище для информации. Коммуникационные сети обеспечивают доступ к информации. Широкая доступность и простой доступ позволяют получать информацию из ERP систем через Интернет.
ERP системы — это строительный блокэлектронной коммерции
Недавно, руководитель приложений электронного бизнеса компании ЗСот заметил: «ERP системы — это строительный блок Е-биз- неса» (Ricadela 1999). Почему?
ERP система предоставляет «центральный клиринговый дом» для информации в реальном времени. Например, в компании Compaq фактически вся база глобальных ежедневных операций доступна в ERP системе компании. Как сказал вице-президент Compaq:
Если мы сегодня продаем продукцию в Швейцарии, мы можем записать, что конкретно мы продаем, полученную прибыль и стоимость этой продукции. Наши информационные технологии могли бы даже предоставить возможность найти следы этой информации в ежедневном отчете о прибылях и убытках, (leresko 1998)
ERP система предоставляет текущую информацию о запасах и ценах, так что фирмы знают, что конкретно они могут продать. ERP система также содержит информацию о продукции, необходимую для планирования потребностей в материалах. Таким образом, при наличии информации о том, что необходима конечная продукция х, могут быть произведены все предметы, необходимые для ее создания. ERP система обеспечивает большую часть инфраструктуры электронной коммер-
ции, предоставляя основную информацию такого рода. Таким образом, ERP системы находятся в центре мира электронной коммерции.
Взаимодействие между предприятиямив рамках электронной коммерции
Источник информации предприятия — это ERP система. Однако существует необходимость обмена информацией между различными предприятиями. Изначально, в качестве основы для передачи большей части такой информации в электронном виде использовался формат EDI (electronic data interchange — обмен электронными данными). Сейчас в качестве другого способа обмена информацией об операциях все чаще используется технология web-форм (web forms technology, WFT). EDI обычно используется при больших объемах операций, в то время как WFT применяется при осуществлении только небольшого числа операций любым из клиентов.
EDI базируется на обмене информацией стандартными элементами (например, «счетами») в стандартном формате (например, стандартная последовательность информации). Для EDI традиционно использовались специализированные сети (value-added network, VAN), обеспечивающие безопасность и инфраструктуру для передачи информации об операциях. Используя WFT клиент предоставляет информацию в форме, доступной в Интернете или в intranet/extranet. Эта информация может быть как непосредственно связана, так и не связана с БД или другим приложением.
Насколько важен EDI для фирм, внедряющих ERP системы? В исследовании, проведенном Deloitte Consulting, этот стандарт указало самое большое число респондентов при ответе на вопрос, какие дополнительные решения были внедрены для ERP системы (Kersnar 1999).
Какова роль EDI и WFT в электронной коммерции? Большая часть ERP систем текущего поколения приспособили EDI, который до сих пор играет важную роль в обработке операций даже для фирм, использующих высокие технологии. Например, как заметил вице-президент компании Compaq: «EDI приносит заказы от некоторых [крупных] «канальных» партнеров» (Teresko 1998). Протокол EDI достаточно надежен и нашел широкое применение в таких операциях электронной коммерции, как «стыковка товаров» при перевозке (о которой будет коротко рассказано далее). Использование WFT растет взрывообразно. Например примерно 85% заказов Cisco размещаются через web-сайт компании (Riggs 1999).
Однако с традиционным EDI возникают некоторые трудности. Во- первых, этот протокол стандартизован, и во многих случаях для него
приходится использовать конкретные процессы и объекты, которые могут не являться оптимальными. В результате изменения процессов и объектов, происходящие со временем, могут быть ограничены структурой EDI. Например, как сказал вице-президент Compaq: «Так как EDI — это действительно последовательный процесс, и он, по сути, диктует некоторый темп того, что вы должны делать, мы будем вынуждены, в конечном итоге, перейти к проведению операций с нашими поставщиками и клиентами в Интернете» (Teresko 1998).
Во-вторых, EDI изначально предназначен для крупных фирм и большого объема операций. Как заметил один из вице-президентов компании Dell:
Крупные пользователи сервиса business-to-business интегрируют свои закупки и ERP системы с нашей системой, так что это будет работа в стиле компьютер-компьютер.
Premier Pages предоставляет бизнес-клиенту защищенные паролем данные о некоторых ценах, которые он обсуждал с нами, и состояние его заказа. Это персонализированное представление данных web-сайта Dell для бизнес-клиентов... Считайте, что Premier Pages находится ще-то в промежутке между общедоступным web- сайтом и действительно интегрированным ERP решением. Крупные клиенты будут применять действительно интегрированное ERP решение, используя Premier Pages в основном для получения информации. Средние и малые предприятия не будут иметь сложного подключения и ERP систем, поэтому они будут использовать Premier Pages в качестве превалирующего метода. (Wagner 1999)
В связи с ограничениями на размер фирм разрабатываются новые возможности, которые интегрируют EDI и технологию web-форм. Например, небольшие поставщики Cisco пользуются для организации взаимодействия с этой компанией услугами провайдера web- сервиса В2В (Karpinski 1999). Третья проблема традиционного EDI — это стоимость. VAN намного дороже Интернета, поэтому фирмы все больше пользуются EDI через Интернет.
Ограничения на использование WFT тоже существуют и, в первую очередь, в условиях, когда инициатор имеет только несколько заказов, а фирма, получающая их, — множество. Если у фирмы-инициатора заказа много операций, то заказ через WFT может для нее оказаться слишком дорогостоящим и отнимать много времени. Клиент
* То есть сервис взаимодействия между компаниями (для его обозначения часто используется аббревиатура В2В). (прим. науч, редактора)
не только должен сделать заказ производителю с использованием WFI； но, кроме того, он должен обновить данные в своей системе. Следовательно, использование WFR удваивает время ввода данных и, таким образом, требует больше персонала.
Широко доступный и простой доступ пользователей
Другая составляющая — это доступ пользователей. Многие ERP системы доступны через Интернет, и пользователи могут использовать его для входа в ERP систему с целью размещения заказов. Например, как сказал Троммер (Trommer 1998), Fujitsu PC Corporation использует свою ERP систему и другое ПО для предоставления возможности (торговому представителю Fujitsu, посреднику или конечному пользователю) размещения заказа через Интернет.
К сожалению, у этого способа есть ограничения. Как заметил менеджер Cambridge Partners (Kersnar 1999): «В настоящий момент, чтобы работать с ERP системой, необходимо быть в офисе». Более того, доступная скорость модема может быть слишком низкой для того, чтобы обеспечить эффективную работу. Подобно этому, для облегчения заказов и реализации взаимодействия в среде клиент-сервер к клиентским компьютерам могут предъявляться некоторые стандартные требования. Однако в случае с Интернетом пользовательские компьютерные среды могут быть абсолютно разнородными. Как результат, один из подходов состоит в предоставлении другой разновидности клиент-серверного доступа, при котором пользователю нужен только браузер и доступ в Интернет. В этой среде пользователь имеет Интернет-доступ как разделяемый во времени клиент, который напрямую связывается с сервером в соответствующей стандартной среде. Этот подход устраняет многие из требований к стандартизации на пользовательском уровне клиент-серверных вычислений, а также расширяет классическую клиент-серверную парадигму до модели с разделением времени, аналогичной используемой в вычислительной среде мейнфрейма. В приложении к данной главе мы предлагаем более подробное описание того, как эта версия клиент-серверных вычислений может быть использована для доступа к ERP системе через Интернет.
Кроме того, как отмечено в главе 4, производители ERP систем для обеспечения доступа к ним разработали порталы. Общая особенность этих порталов — это то, что они базируются на использовании web-браузеров, что повышает комфорт использования ERP сис-
* Browser — программа, используемая для навигации и просмотра информации на web-серверах (прим. науч, редактора}.
ERP СИСТЕМЫ
тем 6ла「0»царя обеспечению доступа к ним через Интернет. На рисунке 14.1 показан портал компании J.D. Edwards ActiveEra, предоставляющий web-доступ к ERP системе компании.
Порталы систем планирования ресурсов предприятий позволяют фирме персонализировать доступ к ERP системам в среде Интернет. Кроме того, порталы предоставляют доступ к некоторым связанным услугам, продвигая, таким образом, электронную коммерцию. Например, порталы SAP предоставляют доступ к информации о дру- 「их продуктах и услу「ах компании и дру「их связанных с SAP производителях.
ERP и заказы товаров клиентами
Возможно самая важная задача коммерции — обеспечение раз
мещения заказов клиентами. К сожалению, размещение заказов —— это процесс, в котором часто возникают ошибки. Например, компания Cisco выяснила, что от 25% (Roberts 1998) до 33% (Messmer 1999) заказов, сделанных с использованием факса, содержали ошибки. Такие ошибки могут привести к задержке поставки или к изменению цены. Когда клиенты узнавали об этом, им приходилось связываться с Cisco по поводу своих заказов. Эти запросы, в свою
очередь, требовали увеличения персонала компании для ответа на вопросы клиентов, что приводило к увеличению расходов и замедлению процесса поставок товаров клиентам. В результате с целью упрощения процесса размещения заказов Cisco обратилась к электронной коммерции.
Рисунок 14-1
Клиенты следят за наличием товаров
В 1996 г. Cisco создала одно из своих первых приложений в области электронной коммерции (Roberts 1998). Через Интернет клиенты могли получить информацию из ERP системы компании, которая позволяла им отслеживать исполнение их заказов и узнавать цены на них. Например, им был предоставлен доступ к ценам, форме и состоянию заказа, и эта информация была доступна семь дней в неделю, 24 часа в сутки. Эта стратегия уменьшила потребность Cisco в персонале, отслеживающем исполнение заказов и отвечающем на вопросы клиентов. Поддержка клиентов стала их собственной задачей.
Клиентские заказы через Интернет
Предоставление клиентам возможности отслеживать исполнение их заказов и находить ошибки было только частью решения Cisco. Возможно более важным вопросом было: «Как для начала устранять ошибки?» На второй год задачей компании было устранить ошибки и предоставить клиентам возможность размещать заказы через Интернет в любое время и в любом месте (Roberts 1998). Имея доступ к информации ERP системы, клиенты могли узнать цекы5 сконфигурировать и разместить заказ.
Чтобы для размещения заказов клиенты использовали Интернет, Cisco гарантировала, что цены и форма заказов будут точными, если клиенты будут использовать web-приложение. В течение четырех месяцев после этого 10% заказов были размещены через Интернет; а к 1999 г; эта цифра увеличилась до 85%.
Преимущество этого способа в том, что клиенты могут размещать заказы с высокой точностью, и через 15 или менее минут он будет в ERP системе Cisco, и клиенты смогут отследить его исполнение (Messmer 1999). Кроме того, в течение тех же 15 минут Cisco может начать производство товаров (Riggs 1999).
Точность системы обеспечивает «конфигурационная машина» (КМ). Она проверяет заказы на распространенные ошибки. Если ошибки найдены, то КМ не позволит клиенту разместить заказ. КМ проверяет всю доступную учетную информацию и информацию о закупках, чтобы установить, например, неверные номера изделий. Од- накоу«цанно「о метода есть и ограничения. Например, закупки совершаются с использованием системы Cisco, а не системы клиента. И это значит, что клиенту необходимо вводить ту же информацию и в свою собственную ERP систему.
Загрузка информации для закупок
В 1998 г. Cisco начала работать со своими самыми крупными клиентами в области интеграции информации о заказах в их системах закупок (например, в их ERP системах). Для этих особенных клиентов новая информация о формировании и размещении заказов, а также о ценах предоставляется раз в день. Эти клиенты могут размещать заказы, используя знакомые им системы, которыми они пользуются ежедневно, и больше нет необходимости дублировать прсщесс, вводя заказ и у себя, и через web-сайт Cisco.
8 чем недостаток открытия доступак информации ERP системы?
Исследование, проведенное AMR (Booker 1999), показало, что даже в индустрии высоких технологий фирмы не хотят разрешать доступ к информации о заказах. Хотя 97% из исследованных фирм имеют web-сайты, только 21% из них разрешает доступ к учетной информации в реальном времени.
Каков недостаток открытия прямого доступа к информации? Во-первых, это соображения безопасности: защита ERP системы, ее информации и передачи данных через Интернет. Как результат, EDI через VAN в некоторых ситуациях будет осуществляться и в дальнейшем. Во-вторых, фирмы обеспокоены тем, что клиенты имеют доступ к «окну», из которо「о видны их процессы. Например, клиенты могут «видеть», как размещенные заказы исполняются компанией. Может быть найдена информация о датах производства товаров или проведения операций. Доступ к информации для отслеживания исполнения заказов дает возможность «увидеть», сколько времени фактически заняло производство продукции или через какое время после размещения заказа это производство началось. В-третьих, доступ к информации из ERP системы должен учитываться с точки зрения возможностей оборудования и ПО. Большое число ин- тернет-запросов может ухудшить работу ERP системы для внутренних целей.
Почему важно предоставлять доступк информации ERP системы?
Почему, несмотря на все сказанное, обеспечение доступа к точной информации ERP системы в реальном времени остается важным? Во-первых, доступ к этой информации может обеспечить точность, как мы видели на примере внедрения компанией
Cisco. Доступ к информации ERP системы гарантирует, что заказанные товары имеются в наличии. Во-вторых, по мнению 84% опрошенных менеджеров по информационным технологиям (Booker 1999) доступ к информации ERP системы может улучшить деловое взаимодействие. Клиенты могут проверить свои счета и получить ответы на свои вопросы, когда захотят. В-третьих, как сказал президент компании Interlink Communications: «Я хочу использовать системы для того, что связано с операциями, и сохранить людей для взаимодействия и поддержки» (Booker 1999). Чтобы клиенты могли найти информацию о состоянии своих счетов и детальную информацию о счетах-фактурах, Interlink открыла доступ к информации из своей финансовой системы Great Plains. Дополнительная стоимость таких запросов фактически равна нулю, а персонал, ранее реализовавший данную функцию, занимается другой работой по поддержке клиентов.
ERP системы и запасы, управляемые поставщиками
В модели Cisco обработкой заказа занимается клиент. Однако во многих случаях этот процесс был сдвинут от клиента к поставщику. Например, компания Procter & Gamble осуществляла мониторинг запросов и взяла на себя обязанность хранить свою продукцию (McKenney and Clark 1995). Для обеих сторон это имело ряд преимуществ. Поставщик имеет больше стимулов хранить свою продукцию, повышая объем продаж. Кроме того, если он управляет запасами, то колебания, вызванные меняющимися или некорректными заказами, могут быть уменьшены. При улучшении хранения своей продукции поставщик может выровнять спрос и, таким образом, лучше контролировать производственные, транспортные и административные ресурсы, а, следовательно, и затраты. Клиент выигрывает за счет того, что некоторая часть функций по обработке заказов выполняется не мм, что также сокращает расходы. Кроме того, если поставщик может хорошо управлять хранением продукции, то должен увеличиться объем продаж. В целом затраты должны уменьшиться, а прибыль вырасти.
Запасы, управляемые поставщиками, предоставляют им доступ к необходимой информации в реальном времени. Доступ должен быть электронным, а информация свежей, в противном случае ухудшится качество решений по запасам — особенно важный аспект управления запасами поставщиком. В мире, базирующемся на ERP, есть два решения, развиваемые для облегчения управления запасами: интеграция через данные по заказам и прямая связь ERP-ERR
Интеграция через обычные данные
Одним из методов управления запасами поставщиком является предоставление доступа к необходимым данным (например, к информации о продажах) производителю. Один из методов ——предоставление поставщику прямого доступа к хранилищу данных, содержащему необходимую информацию. Как сказал вице-президент компании Compaq:
Мы также специально разработали некоторый инструментарий поверх системы SAP, дающий возможность использовать способности хранилища данных ... Мы обеспечили возможность EDI помещать информацию в наше хранилище данных. Каждую неделю наши поставщики используют EDI для того, чтобы отчитаться о возможности и состоянии поставки, (leresko 1998)
Прямая интеграция ERP систем
ERP системы все больше интегрируются напрямую для обеспечения управления запасами поставщиками. Например, прямая интеграция ERP систем была осуществлена в компании Colgate:
Colgate планирует использовать свою сеть для получения информации о запасах клиентов и предоставить возможность своим поставщикам получать информацию о ее запасах. Компания даже снабжает своих основных поставщиков компьютерами с установленной на них системой R/3, напрямую подключенной к системе Colgate. (Brownlee 1996, с. R17)
К сожалению, прямое взаимодействие систем — это не просто вопрос разрешения протекания операций между двумя источниками. Чтобы различные системы были действительно интегрированы, некоторые МОПы этих систем (по крайней мере для конкретных операций) должны совпадать. В противном случае потребуются дополнительные усилия по интеграции.
ERP системы и производство на заказ
Для удовлетворения спроса фирмы изначально использовали подход «производство на основе прогноза». Данный подход заключается в прогнозировании спроса и производстве продукции и соответствующих запасов для его удовлетворения. Однако для
быстро меняющейся продукции (например, компьютеры) такой подход может быстро привести к накоплению устаревших запасов. В результате все больше используется новая стратегия, называемая «производство на заказ», особенно в производстве продукции высоких технологий, которая быстро устаревает. Данная стратегия не предусматривает производства продукции, пока в ней действительно не возникает потребность. При использовании данного подхода организации максимизируют гибкость, храня все свои запасы фактически в виде сырья.
Подход «производство на заказ» замещает запасы технологиями информационных систем (Teresko 1998). Переход от «производства на основе прогноза» к производству на заказ требует представления информационных технологий и процессов на уровне всего предприятия. Как заметил вице-президент Compaq: «Мы выбрали систему планирования ресурсов SAP R/3 для того, чтобы иметь стандартный набор правил ведения бизнеса для оптимизации решений, которые принимаются в центре и должны быть исполнены на местах» (Teresko 1998).
Важная часть подхода «производство на заказ» ——«конфигурационная машина», обеспечивающая подробную информацию о материалах, необходимых для производства продукции. Например, если производится компьютер, то конфигурационная машина детализирует задействованные процессы и компоненты (например, память, жесткий диск), которые нужно использовать. Как сказал Троммер (Trommer 1998): «Конфигурации новой модели объединяется моделью ERP системы компании Compaq с информацией о возможности ее создания и имеющихся для этого компонентах». Возможность предоставления ERP системой информации в реальном времени необходима для предоставления информации, требующейся для производства на заказ.
На определенном этапе возможно соединение ERP системы с другой ERP системой для обеспечения производства на заказ, как это было описано вице-президентом компании Dell (Wagner 1999):
Представьте себе интеграцию, при которой, по сути, ERP система клиента автоматически создает заказ. Он совершенно корректный. Заказ не может быть некорректным, так как друг с другом общаются системы, — человеческий фактор отсутствует. Заказ идет сразу на производственную линию, и через 20 секунд устройство начинает создаваться, так что вы сэкономили огромное время цикла.
Как только устройство готово, его доставляют клиенту. Счета передаются в электронном виде в систему клиента, и получение денег начинается сразу. Единственное ограничение — это время, требующееся на создание устройства.
ERP система и связи с реселлерамис помощью механизма электронной коммерции
Системы планирования ресурсов предприятий также могут быть использованы для обеспечения электронной связи с партнерами цепочки поставок — например, с реселлерами. Компания Cisco не занимается хранением готовых товаров, и большая часть продаж осуществляется через посредников. Хотя большинство этих посредников взаимодействуют с дистрибьюторами , они предпочитают размещать заказы напрямую в Cisco через web-сайт. Таким образом, важной задачей является создание электронных связей между реселлерами и дистрибьюторами. Cisco организовала такую связь через свои ERP системы, соединенные с web-сайтами. Как сказал Ригс (Riggs 1999): «Вместо того чтобы направлять заказы реселлеров напрямую на предприятия, заказы могут быть направлены в ERP систему дистрибьютора. Последний может добавить характеристики, такие как предложение реселлеру скидки при условии закупки определенного объема продуби».
ERP системы и «стыковка при доставке»
Одна из самых интересных операций, возникших в рамках электронной коммерции, является «стыковка при доставке», которую можно определить как «услуга, при которой для единовременной доставки клиенту собираются и объединяются партии товаров из различных источников» (Dawe 1997).
Стыковка при доставке подразумевает либо соединение грузов и их отправку, или синхронизацию их доставки. В первом случае отдельные компоненты заказа могут храниться в разных местах и сли-
ваются при доставке. Во втором случае обеспечивается одновременная доставка многочисленных частей заказа. Стыковка при доставке может сильно повлиять на запасы фирмы. Вместо того чтобы отправлять все составные части в одно центральное место и затем соединять их и отправлять клиентам для получения заказа, эти части можно доставлять клиентам прямо с производства. При «стыковке при доставке» широко используется EDI (см. Cooke 1998), и требуется информация в реальном времени, которая может быть получена из ERP системы.
Приведем пример использования метода «стыковки при доставке» (Anonymous 1998). Компания Dell Computer сама не производит мониторы, которые продает в центральной части Техаса. Чтобы сократить запасы и затраты на транспортировку для компании Dell, производитель мониторов доставляет их в различные подразделения компании UPS , расположенные по всей стране. Доставка мониторов в UPS назначается на то же время, что и доставка компьютеров. Клиенты получают одну объединенную поставку. Таким образом, Dell никогда не хранит мониторы на своих складах.
Стыковка при доставке — явление, возникшее в некоторых видах производства относительно недавно. Например, 28 сентября 1998 г. в «Networked Commerce News» Cisco сделала следующий анонс:
Доступно новое решение объединенной поставки
Новое решение объединенной поставки компании Cisco — «Стыковка при доставке» — стало доступно для всех клиентов в Соединенных Штатах. «Стыковка при доставке» — это новая опция поставки Internetworking Product Center (IPC), созданная для упрощения получения и оплаты заказов. При использовании «Стыковки при доставке» все части заказа на поставку доставляются в одно и то же время, и выписывается единый счет. Это позволяет избежать многочисленных перевозок и счетов, упрощая для вас ведение бизнеса с Cisco. Для выбора решения «Стыковка при доставке» просто выберите опцию поставки «Merge Order» («слияние заказа») в «Step 6, Taxes and Shipping» («шаг 6, сборы и доставка») в контрольной таблице заказов IPC.
Как видно из этого примера и из предшествующего описания, «стыковка при доставке» предъявляет к ERP системе кон-
* «Единая служба доставки» (прим. науч, редактора).
** Продуктовый центр, работающий через Интернет (прим. науч, редактора).
кретные требования. Например, хотя продукция поступает из нескольких мест, существует единый заказ на поставку и единый счет: счета, поступающие из каждого места нахождения продукции, отсутствуют. ERP система должна быть способна объяснить продажи товаров, которые еще не «получены» для продажи клиентам. Пункты нахождения товаров обмениваются важной информацией при помощи EDI.
Резюме
Системы планирования ресурсов предприятий, коммуникационные сети, использующие EDI и WFT и обеспечение доступа пользователей —три строительных блока электронной коммерции. Эти блоки не являются независимыми, для обеспечения успеха электронной коммерции они должны быть тесно связаны. ERP системы предоставляют информацию, коммуникации связывают многочисленные предприятия, а широкий доступ обеспечен благодаря использованию Интернета и браузерных интерфейсов.
Мы рассмотрели роль ERP систем в некоторых операциях электронной коммерции. Мы выяснили, что ERP системы играют важную роль в поиске товаров клиентами, заказах ими товаров, в управлении запасами поставщиками, производстве товаров на заказ, связях с реселлерами и «стыковке товаров» при доставке. Эти операции привели к реинжинирингу процессов, лежащих в основе электронной коммерции. ERP системы являются центральными репозиториями информации — это инфраструктура и технология, делающие возможными радикальные перемены в процессах, поддерживающих электронную коммерцию.
Литература
Anonymous (1998). «Order Assembly Centers: Guarantee Same-Day Shipment in Any Quality». Modern Materials Handling, May.
Bookei; E. (1999). «Web to ERP — ERP Stage II: Outsiders Invited In». Internet
Week, October 25, (www. techweb.com).
Brownlee, L (1996). «Overhaul.» Wall Street Journal, November 18, pp. R12, R17.
Cooke, J. (1998). «Custom Built with Speed». Logistics Management and Distribution Report, January, pp. 54-7.
Dawe, R. (1997). «Move It last, Eliminate Steps». Transportation and Distribution, September.
Karpinski, R. (1999). «EDI Developer Extends E-Trading Boundaries». Internet Week, May 3, p. 10.
Kersnar; J. (1999). «The Tangled Web We Weave». CFO Europe, July/August, pp. 37-44.
McKenney, J, and Clark, T. (1995). «Procter & Gamble: Improving Consumer Value through Process Redesign». Report no. 9-195-126, Harvard Business School, Cambridge, MA.
Messmer, E. (1999). «Secrets of the E-Commerce Stars». May 25, (www.cnn.com).
Ricadela, A. (1999). «Cisco, 3Com Aim at ERP». iweek, August 2, (www.iweek.com).
Riggs, B* (1999). «Cisco Simplifies Business». Information Week, December 13, p. 92. Roberts, B. (1998). «Е-Commerce Poster Child Grows Up». Datamation, August, (www.datamation.com).
Teresko, J. (1998). «Replacing Inventory with IT». Industry Week, April 6, (www.industryweek.com).
Trammer, D. (1998). «ВТО: New Order of Business». Electronic Buyer's News, November 16.
Wagner, M. (1999). «Next Step： Remove All Human Intervention». Internet Week, October 25.
ПРИЛОЖЕНИЕ 14-1
Использование ERP системы OneWorld компании J.D. Edwards
8 Leventhal School университета Южной Калифорнии:интервью с профессором Лесом Потером
Лес Потер (Les Porter), директор Центра бухгалтерских решений, является преподавателем в бухгалтерской школе Leventhal School Высшей школы бизнеса университета Южной Калифорнии. Боб Киду, на которого мы также ссылаемся в интервью, преподает в Leventhal School. Keck Center (Keck)——это группа поддержки вычислительных средств и сетей Высшей школы бизнеса.
Какова точка зрения факультета
в отношении ERP систем?
Мы считаем, что для того, чтобы наши студенты стали ценными специалистами, они должны иметь практический опыт использования реальных вещей. Такой точки зрения придерживаются сегодня
многие факультеты. Все стараются дать своим студентам практический опыт, настолько близкий к реальности, насколько возможно.
В результате мы решили интегрировать в наш учебный план несколько программных пакетов для предприятий. Одним из этих пакетов был клиент-серверный пакет OneWorld компании J.D. Edwards.
Как вы внедршш OneWorld:
автономно и刀и как клиент-серверное решение?
При первоначальном внедрении J.D. Edwards у нас было две возможности: внедрить OneWorld в демо-версии или в полноценной среде клиент-сервер. Хотя некоторые факультеты внедрили J.D. Edwards в демо-версии, мы отказались от этого варианта с самого начала. Это означало бы, что каждый пользователь должен был бы для выполнения задания в лаборатории всякий раз использовать одну и ту же машину, так как его данные находятся именно в ней. Так как машина находится в лаборатории, она доступна другим пользователям, которые могут испортить ее или эти данные. Если что-то случится, пользователь на какое-то время потеряет свои данные или доступ к машине.
Приняв во внимание проблемы материально-технического характера, т. е. то, что студенты могут работать только в лаборатории и только на одной машине, мы решили избежать этих трудностей, внедрив систему в клиент-серверной среде. В конечном итоге мы стали третьей организацией в мире, работающей с системой OneWorld в этой среде.
Каковы уникальные требования со стороны OneWorld?
OneWorld ——это тип ПО «точно вовремя», которому необходима операционная система Windows NT для того, чтобы предоставить студентам доступ к инструментальным средствам. Загрузка необходимых пользователю модулей производится тогда, когда они нужны. Система использует распределяющий сервер, который следит за ПО на персональных компьютерах пользователей. Чтобы увидеть, имеет ли клиент самую последнюю версию или вообще соответствующее ПО, сервер заходит на клиента. Если ПО нет или установлена его старая версия, сервер загрузит клиенту новую версию ПО.
Это имеет некоторые преимущества и, по крайней мере, один недостаток. Во-первых, компьютеры пользователей не «забиваются» ПО, которое им не нужно. Во-вторых, ПО нужно установить только на распределяющий сервер, и система сама обо всем позаботится. Та-
ким образом, [обслуживающему персоналу] нет необходимости обходить всех клиентов и модернизировать их ПО. К сожалению, для нас проблема заключается в том, что, когда мы используем систему в аудитории, наши студенты используют все ее модули. В конечном итоге каждый студент загружает все. Таким образом, у них возникает [вместо «тонкого» клиента, что предполагает модель клиент-сервер] не просто «толстый», а «жирный» клиент. В результате получилось, что мы, в конечном итоге, разместили в лабораториях несколько таких «толстых» специализированных NT-клиентов.
Какие проблемы возникли у вас с версией клиент-серверного ПО?
У нас были три проблемы, первые две из которых, возможно, уникальны для университета. Во-первых, у нас в университете существуют многочисленные уровни защиты, не контролируемые централизовано. Со временем в архитектуре системы уровни защиты наслаивались один на другой. В результате для использования наборов инструментальных средств для всего ПО нам пришлось найти решение нашей проблемы с защитой. Группа Keck разработала решение нашей проблемы и продолжает заниматься защитой.
Во-вторых, у нас была проблема с ODBC -драйверами. Драйверы ODBC обычно позволяют одним приложениям просматривать данные других приложений. В системе J.D. Edwards требования к ODBC-драйверам статические. В закрытой среде статические ODBC- драйверы не представляют проблемы. Однако в условиях университета они становятся кошмаром. Каждый раз, когда ще-то осуществляется модернизация системы, ODBC-драйверы меняются, и возникает несоответствие. ODBC-драйверы стали нам хорошо знакомы. Боб помог написать некоторую поддерживающую информацию для J.D. Edwards, касающуюся ODBC-драйверов.
В-третьих, нам повезло, что организация Parker & Parker lab выделила деньги для лаборатории на приобретение специальных «толстых» клиентов. Однако мы смогли разместить только две машины, достаточно мощные для студентов. Данные находились на сервере, поэтому неважно, какой из двух, но это должен был быть один из этих
* ODBC обозначает «open database connectivity» (открытый интерфейс доступа к БД) и является интерфейсом прикладного программирования (application programming interface, API) для доступа к БД, использующих в качестве языка доступа SQL (structured query language — язык структурированных запросов). ODBC базируется на CLI (call level interface — спецификация метода запросов к БД на языке SQL) от Х/Open и API \SO/\EC(прим, автора).
«толстых» клиентов. Кроме того, студенты имели ограниченный доступ к машинам, так как они могли пользоваться ими, только конца библиотека была открыта. Поэтому в наших условиях клиент-серверная технология не предоставляла большого преимущества.
Трудности представления доступа
Мы хотим предоставить нашим студентам доступ 7x24(7 дней в неделю, 24 часа в сутки) к любым вычислительным ресурсам Leventhal School. Студенты работают не в то время суток, конца работает факультет. Таким образом, нам было важно дать студентам возможность работать с этим ПО в нужное им время, а не в то время, которое удобно главному библиотекарю. Мы могли сделать это только через Интернет. К сожалению, мы не знали как.
Сервер Citrix
В прошлом году я посетил несколько занятий в рамках конференции J.D. Edwards в Колорадо. Одно занятие (кстати, не та презентация, на которую я шел) было презентацией Citrix. Этот парень демонстрировал ПО с использованием Интернета для связи со своим офисом в Пенсильвании, подключенным к лаборатории в Денвере. Время ответа у него было лучше, чем у меня на практических занятиях с использованием лаборатории в одном здании. Меня это взволновало ——это было действительно здорово!
Citrix предоставляет клиенту, работающему в каком-то другом мбстб окно. У нас есть сервер Citrix, который, согласно нашей лицензии, может запускать до 20 клиентов на этой одной машине. Возвращаются старые добрые времена разделения времени*. Используя это ПО, он может управлять 20 клиентами, поэтому с тех пор, как он находится прямо в лаборатории, нам не важно, насколько «толст» наш клиент. Мы можем установить его и управлять им в лаборатории, как Windows NT Мы управляем всей его средой. Нам не нужно беспокоиться о размере клиента: у нас достаточно дисковых накопителей, он имеет 1 Гбайт памяти, и у него два процессора ——это наш самый дорогой блок. Нам не нужно волноваться о том, что ODBC драйверы изменятся.
Это также большой шаг вперед в управлении нашим ПО. При модернизации ПО нужно осуществить изменения только на сервере и в этом единственном клиенте, и у всех будет одинаковое ПО. Нужно за-
времени (прим. науч, редактора).времени (прим. науч, редактора).Имеется в виду, что работа с мейнфреймами шла в режиме разделения
времени (прим. науч, редактора).
времени (прим. науч, редактора).
ботиться только о защите клиента и сервера. Об ODBC-драйверах беспокоиться не нужно.
Студенты имеют круглосуточный доступ из люб。访 точки планеты с любого компьютера. Они могут использовать Linux, Мас или Windows З.Г на Intel 486, если есть web-браузер и доступ в Интернет. Windows NT им не нужен.
Однако в де访ствительности наилучшим образом он работает с MS Internet Explorer с плагином (plug-in) Citrix. У нас нет проблем ни с кем, кто использует самую последнюю версию Internet Explorer, но у нас были проблемы с некоторыми более старыми версиями. Это самая блестящая вещь для предоставления услуг студентам, какую я только видел.
Мы сохранили свои прибыли в этом году. Как вы знаете, мы только что переехали в новое учебное здание, Popovich Hall. Так как оно было совершенно новым, когда осенью начались занятия, сетевых приложений не было. Перед нами стоял вопрос: «Как нам получить доступ к приложениям для занятий?» Мы просто положились на сервер. В то время как другие пытались решить эту проблему, все, что нам было нужно, — это доступ в Интернет для получения доступа к серверу Citrix.
Я не думаю, что есть хотя бы еще один факультет в стране, который использует Citrix для своих приложений.
Вы можете мне рассказать, как он работает?
Чтобы получить доступ к серверу Citrix и различным приложениям, я выхожу на MyHomePage, являющейся просто локальным НТМ1?**-файлом (рис. 14.2), это может быть и web-страница. После нажатия на значок «Citrix» появляется окно регистрации пользователя Windows NT для сервера Citrix (рис. 14.3). На терминальном уровне доступны такие программы, как ACL для Windows, Great Plains, MAS 90, New Visio и OneWorld (рис. 14.4). При нажатии на значок «OneWorld» выводится окно регистрации пользователя для программы OneWorld (рис.14.5), через которое непосредственно доступна данная программа (рис. 14.6).
Рис. 14.2
Что заставило это работать?
Одним из наших преимуществ было то, что фирмы «Большой пятерки», оказывающие профессиональные услуги, и деньги факультета помогли нам получить то, что нам нужно. Вопрос не в том, делаем ли мы это, а в том, насколько быстро мы можем это делать. Деньги были важным вопросом. Мы купили блок для сервера Citrix. В целом сумма составила 2 000 долларов за каждую из 20 пользовательских лицензий, включая оборудование и ПО, не зависимое от приложений.
Но дело не только в деньгах. J.D. Edwards работает во многом благодаря Майклу Саймонсу из Arthur Andersen. Мы могли позвонить Сюзанне Каракостас из Arthur Andersen и получить техническую поддержку.
Рис. 14.3
Рис. 14.4
Это технические специалисты, которые потратили много времени, работая с людьми из J.D. Edwards, и система стала функционировать. Не знаю, что бы мы делали без их поддержки. Специалисты из Keck Center приложили массу усилий, чтобы наш сервер Citrix работал. Фактически Keck Center продолжает поддерживать и управлять этим сервером.
Мы с Бобом не технические специалисты. Однако мы обвиняли друг друга, если что-то не получалось, и готовы были принять на свой счет удачные моменты. Хотя, когда Боба спросили, почему в университете Южной Калифорнии в отличие от остальных система работала, он ответил: «Когда Лес сказал мне, что система должна быть установлена и работать в аудитории, я подумал, что выбора нет». Нам просто пришлось идти до конца.
Рис. 14.5
Рис. 14.6
Каковы ваши планы на ближайшее будущее?
Все необходимые студентам Leventhal School приложения (J.D. Edwards, Great Plains, MAS 90, Platinum, ACL, Pro Carta и др.) находятся на сервере Citrix, и доступны круглосуточно, 7 дней в неделю. Кроме того, Citrix предоставляет студентам возможность доступа к БД на CD. Мы уже договариваемся об установке второго сервера Citrix с автоматическим переключением. Это на случай, если один сервер не будет работать.
15
РИСКИ, СВЯЗАННЫЕ с ERP СИСТЕМАМИ
Факторы успехов и неудач
Не все проекты внедрения ERP систем являются успешными. Проекты завершаются успешно или неудачно по различным причинам. Хотя мы указали на некоторые элементы риска или неудач внедрения ERP систем, цель данной главы ——представить основу для определения риска и определить некоторые дополнительные риски, которые могут привести к успешному или неудачному внедрению ERP систем.
Риск ——это то, что дело может пойти не так, как надо. При правильных действиях риск может стать фактором успеха, в противном случае — фактором неудачи. Факторы успехов и неудач — это две
стороны одного и того же риска. Между риском и прибылью существует непосредственная связь. Подвергнув фирму риску, можно в конечном итоге получить большую прибыль. Например, как будет показано ниже, при стыковке ERP системы с другими приложениями увеличивается не только риск, но и потенциальная польза от проекта.
Одна из моделей категоризации видов рисков, связанных с ERP системами, приведена на рис. 15.1. В данной таблице виды рисков категоризируются по двум аспектам: этап жизненного цикла ERP системы и вид риска (технический, связанный с бизнесом и организационный).
Виды рисков
Риски возникают на протяжении всего жизненного цикла ERP систем ——от принятия решения о внедрении до периода после запуска системы, включая вопросы обучения. Виды рисков и степень их влияния на организацию варьируются по мере прохождения жизненного цикла ERP системы.
Технические риски — это риски, связанные в основном с технологией обработки информации. Например, технология, использованная в ERP системах, включает операционную систему, реляционную БД, технологию клиент-сервер, требования к сети и ПО. Бизнес-
ОрганизационныеОрганизационныеТехнические Связанные с бизнесомТехнические Связанные с бизнесомПринятие решения о внедрении ERP системыПринятие решения о внедрении ERP системыВыборERP системыВыборERP системыПроектированиеВнедрениеПосле запускаОбучениеПроектированиеВнедрениеПосле запускаОбучениеРис. 15.1. Матрица рисковРис. 15.1. Матрица рисков
Организационные
Организационные
Технические Связанные с бизнесом
Технические Связанные с бизнесом
Принятие решения о внедрении ERP системы
Принятие решения о внедрении ERP системы
Выбор
ERP системы
Выбор
ERP системы
Проектирование
Внедрение
После запуска
Обучение
Проектирование
Внедрение
После запуска
Обучение
Рис. 15.1. Матрица рисков
Рис. 15.1. Матрица рисков
риски связаны с моделями, объектами и процессами, которые выбираются и адаптируются в рамках внедрения ERP системы. Бизнес- риски связаны с выбором набора МОПов фирмы, которые должны быть внутренне непротиворечивы и соответствовать МОПам деловых партнеров. Организационные риски связаны со средой (персонал и структура организации), в которой выбирается и внедряется система.
В данной главе виды рисков будут размещены по разным категориям, возможно, не уникальным.
Исследование рисков
В недавно проведенном исследовании (Austin and Cotteleer 1999) анализируются осознаваемые риски проектов внедрения ERR Результаты, приведенные в табл. 15.1, показывают, что организационные риски выше, чем бизнес-риски, и что последние выше, чем риски технические.
Таблица 15.1. Осознаваемые риски проектов внедрения ERP систем (%)
Уровень риска
Виды рисков
Технические
Связанные с бизнесом
Организационные
Очень низкий
10,5
4,5
1,5
Низкий
22,5
23,0
8,5
Средний
39,5
32,5
18,5
Высокий
15,0
26,0
37,5
Очень высокий
11,5
14,5
35,0
Примечание: Базируется на усредненных результатах 1998 и 1999「「(Austin and Cotteleer 1999). Из-за незначительного округления числа в некоторых колонках не дают в сумме 100%.
В частности, исследование показывает, что организационные риски рассматриваются как риски «умеренные до очень высоких». Подобным же образом, число ответов, определяющих биз- нес-риски как более высокие, превышает соответствующее число ответов, касающихся технических рисков. Хотя технические риски важны, бизнес и организационные риски доминируют. Проблемы, связанные с техническими рисками, возможно, проще всего устранить путем простой модернизации (например, большая мощность сервера).
Общие технические виды рисков
Чтобы использовать ERP системы, необходимы изменения в технологиях. Когда фирмы внедряют ERP системы, они переходят к новым технологиям — другим операционным системам, реляционным БД, технологии клиент-сервер, сетевым системам — и, соответственно, к другим процессам. Однако новые технологии порождают новые виды рисков. Большинство их являются общими для этапов жизненного цикла, и они в данном параграфе рассматриваются отдельно.
Операционные системы
Операционные системы имеют различные возможности и средства управления, они требуют различных знаний. Таким образом, при внедрении ERP систем фирмам необходимо выбрать операционную систему и нанять людей, которые умеют с ней работать. Первоначально ERP системы были разработаны для среды UNIX и внедрены в нее. Однако после того как Microsoft внедрила SAP в среду Windows N[ другие фирмы могли последовать ее примеру (Bashein, Markus, and Finley 1997). До этого времени использование операционной системы Windows NT ограничивалось небольшими внедрениями. Выбор операционной системы ——это еще одно решение, которое может повлиять на знания и персонал, необходимые для внедрения и обслуживания ERP системы.
Клиент-серверные вычисления
Клиент-сервер ——это доминирующая форма вычислений, используемая для ERP систем. Однако во многих случаях традиционные системы функционируют в вычислительной среде мейнфрейма. В результате знания фирмы и ее опыт могут основываться на другой форме обработки данных и, следовательно, может возникнуть недостаток знаний и персонала для новой вычислительной среды, особенно если клиент-сервер имеет одну из более новых конфигураций, таких как web-доступ к клиенту с разделением времени (см. Приложение 14-1).
Кроме того, в средах клиент-сервера могут существовать другие структуры управления. В средах мейнфрейма фактически вся обработка данных происходит на мейнфрейме. В результате прикладываются значительные усилия для обеспечения «непробиваемости» мейнфрейма. Например, доступ ограничен и физически, и виртуально, для этого также используются вспомогательные устройства. Однако в среде клиент-сервер такие средства управления доступом могут быть или ограничены, или не используемы в той
же степени. Хотя сервер и мейнфрейм должны управляться аналогичными средствами, недостаточное знание среды клиент-сервера или внимания к ней иногда делало сервер уязвимым. Кроме того, в среде клиент-сервера распределенная между клиентом и сервером обработка данных означает, что общая вычислительная среда более доступна и уязвима. Таким образом, существуют новые виды рисков, связанных с внедрением технологии клиент-сервер.
Возможности сети
Системы планирования ресурсов предприятий в большой степени зависят от лежащей в их основе сети, обеспечивающей широкий доступ пользователей к распределенным клиент-серверным системам, особенно если доступ предоставляется через Интернет, intranet или extranet. В этих условиях сеть, в конечном итоге, влияет и на защиту системы, и на ее возможности.
Чтобы гарантировать общую защиту ERP системы, нужно, чтобы сеть была защищена. Несанкционированный доступ к сети может стать первым шагом на пути к несанкционированному доступу к ERP системе. Пропускная способность сети должна быть достаточной для предоставления доступа к ERP системе и любым другим приложениям, поддерживаемым сетью. В противном случае система будет работать слишком медленно или не так, как предполагалось.
База данных
В то время как традиционные системы могут хранить информацию в нескольких БД, реляционные БД хранят информацию в одном месте. Если с этой БД что-то случится, вся информация может быть утеряна. Таким образом, необходимо соответствующее резервирование БД предприятия.
Связи с другими системами
и независимость вычислительной среды
Существуют две другие переменные, определяющие технические риски. Во-первых, ERP системы могут быть установлены либо как независимые системы, либо они могут быть соединены с другими системами. Во-вторых, ERP система может либо иметь собственную независимую сеть и вычислительную среду, либо она может делить эту среду с другими приложениями. Взаимодействие между этими переменными представлено на рисунке 15.2.
При соединении ERP системы с другими системами увеличивается сложность и, соответственно, степень риска, приводящая в не-
(Easd。Hpesis。s arax^5HSSSX3m^(Easd。Hpesis。s arax^5HSSSX3m^Соединение с другими приложениямиРис. 15.2. Взаимодействие среды и соединения с другими приложениями.Соединение с другими приложениямиРис. 15.2. Взаимодействие среды и соединения с другими приложениями.sxxramoas^.-—^ arax2oxofe<sxxramoas^.-—^ arax2oxofe<
(Easd。Hpesis。s arax^5HSSSX3m^
(Easd。Hpesis。s arax^5HSSSX3m^
Соединение с другими приложениями
Рис. 15.2. Взаимодействие среды и соединения с другими приложениями.
Соединение с другими приложениями
Рис. 15.2. Взаимодействие среды и соединения с другими приложениями.
sxxramoas^.-—^ arax2oxofe<
sxxramoas^.-—^ arax2oxofe<
которых случаях к гибельным последствиям. Например, «провалом» внедрения SAR о котором много писали, было внедрение в компании FoxMeyer Drugs. Это внедрение было не просто внедрением ERP системы. Как сказал Джеситус (Jesitus 1997), это было внедрение SAP и ПО для управления складами, и при этом требовалась их интеграция. Кроме того, в это же самое время осуществлялся переход к использованию робототехники на основном складе. В результате, проект был чрезвычайно сложным и, в конечном итоге, потерпел неудачу.
Относительно второй переменной: если система внедряется в среде с несколькими приложениями, то риск, связанный с этими другими приложениями, станет также относиться и к ERP системе. Если ERP система имеет свою собственную среду, то ее проще контролировать. Кроме того, эта среда может быть переделана под конкретные нужды ERP приложения.
Хотя в верхнем правом квадранте риск выше, потенциальная прибыль тоже самая высокая. Преимущества ERP системы лучше всего реализуются, если она интегрирована и связана с другими приложениями.
Технические риски и жизненный цикл ERP систем
Кроме общих технических рисков, на каждом этапе жизненного цикла ERP систем существуют конкретные технические виды риска. Эти риски относятся к обработке данных, ПО, сетям и другим техническим аспектам.
Принятие решение внедрять или нет ERP систему
На принятие решения о внедрении ERP системы может повлиять текущее техническое состояние фирмы. Фирмы со значительными возможностями передовых технологий могут лучше осознать технические риски, связанные с внедрением. Те же фирмы, которые не обладают передовыми технологиями, возможно, не смогут оценить технические риски, и могут вообще не осознать их до внедрения ERP системы.
Технологические риски могут быть минимизированы при использовании конфигураций, проверенных на практике другими фирмами. Как сказал Стейн (Stein 1997а): «Люди сами себе создают сложности, выбирая не ту технологию».
Выбор ERP системы
При выборе ERP системы необходимо выбрать как оборудование, так и ПО. Соответствующий риск будет варьироваться в зависимости от компании.
Обычно основной вопрос ——это соответствие оборудования требованиям обработки данных. Для вертикально-интегрированных компаний выбор оборудования, которое у них уже есть, — способ минимизировать некоторые риски. Например, Siemens Power Company (Hirt and Swanson 1998) в качестве вариантов выбора изначально рассматривала оборудование Hewlett-Packard (HP) и IBM. Однако в конечном итоге было выбрано оборудование от Pyramid, компании, подконтрольной Siemens, коща Pyramid предложила ту же цену, что и Hewlett-Packard и IBM, указав при этом, что продукция будет доставлена из Германии в течение 24 часов. Это решение позволило минимизировать риск, связанный с выбором поставщика, не относящегося к семейству компаний Siemens.
Ни одно ПО не будет оптимальным для всех. Фактически, весь процесс выбора ПО ——процесс политический, и при любой системе оценки числами можно манипулировать. Кроме того, требования меняются. В результате всегда существует риск выбора ПО, которое в течение длительного времени не будет соответствовать нуждам фирмы.
Проектирование, внедрение и запуск ERP системы
Технические виды рисков, связанных с проектированием, внедрением и запуском системы, имеют несколько источников, включая вопросы обработки данных и сетей.
При использовании вычислительной среды клиент-сервер, как и любой другой вычислительной среды, можно недооценить требова-
ния обработки данных, особенно, если доступ к системе обеспечивается через extranet. При начальном внедрении компания Cisco не располагала достаточными вычислительными мощностями (Cotteleer, Austin and Nolan 1998). К счастью для Cisco оборудование было закуплено по причине обещанной производительности, а не в связи с его определенной конфигурацией, поэтому производитель должен был устранить проблему.
Пропускная способность сети также может определить общий успех внедрения системы. Из обсуждения с консультантом из PricewaterhouseCoopers стала понятна степень, в которой сеть может ограничить успешность работы системы. В одном случае при тестировании пропускной способности сети было обнаружено, что каждая операция требовала 10 секунд от ее инициирования на клиенте до ее фиксации сервером. Быстрый подсчет показывает, что такая сеть могла бы обрабатывать только шесть операций в минуту, 360 операций в час или 3 600 операций за десятичасовой рабочий день. Для крупной фирмы, осуществляющей буквально миллионы операций (заказы и т. д.) в год, такая инфраструктура недостаточна. Таким образом, должно быть соответствие между возможностями передачи данных и требованиями их обработки.
Обучение персонала
Новые технологии требуют получения всеми служащими фирмы новых знаний о том, как внедрить и использовать эту технологию, и как она способствует использованию ERP системы. Можно или обучить существующий персонал, или найти новых служащих. В любом случае ERP система может потребовать наличия служащих с различными способностями и навыками, что приведет к изменениям в персонале. Любые значительные изменения в персонале сами по себе достаточно рискованны.
Бизнес-риски
Бизнес-риски связаны с (1) выбором фирмой моделей, объектов и процессов, (2) с тем, насколько хорошо эти МОПы работают в организации и (3) с тем, насколько хорошо они способствуют взаимодействию с фирмами-партнерами (например, производителями и поставщиками). Кроме того, бизнес-риски связаны с тем, насколько хорошо система позволяет компании конкурировать.
Принятие решения, внедрять или we внедрять ERP систему Недостаточные ресурсы ——большой риск, влияющий на принятие решения о внедрении ERP системы, и основания, использованные для этого решения, могут также вылиться в бизнес-риск. Не внедрить ERP систему ——значит отказаться от инфраструктуры, которая могла бы быть использована для интеграции звеньев цепочки поставок и для поддержания конкурентоспособности.
Наличие достаточных ресурсов — одно из самых важных требований. При отсутствии достаточных ресурсов ERP система создает огромный бизнес-риск. Системы планирования ресурсов предприятий могут потребовать большого расхода ресурсов — обычно это миллионы, а иногда и сотни миллионов долларов. Например, компания FoxMeyer планировала потратить на внедрение SAP 65 млн. долларов. Однако, принимая решение о внедрении ERP системы, фирмы могут идти на несообразный расход ресурсов. Фирмы, внедряющие ERP системы, могут обанкротиться или (отчасти) из-за проекта (FoxMeyer), или совершенно независимо от него (Geneva Steel)- Компания FoxMeyer заявила в суде, что внедрение SAP было одной из причин ее банкротства, и сейчас FoxMeyer судится и с SAR и с Andersen Consulting (см. Radosevich 1998). В конечном итоге, SAP была внедрена фирмой, которая приняла на себя руководство FoxMeyer. Компания Geneva Steel объявила о банкротстве через день после того, как система SAR стоившая компании 8 млн. долларов, была внедрена.
Как уже было сказано в главе 7, технологические резоны могут обеспечить основу для расчета затрат и прибыли от внедрения ERP системы. Однако эти резоны не обеспечивают основы для принятия решений относительно МОПов. Таким образом, фирмам необходимо решить, какие процессы они должны изменить (и как изменить) в начале жизненного цикла ERP системы. Эти изменения в процессах могут быть затем использованы для выбора МОПов и оценки успешности внедрения. В противном случае фирма рискует не получить основы для выбора МОПов.
Принятие решения о внедрении ERP системы может быть важным для будущих партнерских отношений. Например, фирмы все больше интегрируют звенья цепочки поставок через ERP системы. В результате, решение о внедрении ERP системы может повлиять на способность фирмы стать частью формирующихся партнерских отношений в цепочках поставок. Отказ от внедрения ERP системы может, таким образом, привести фирму к потере таких возможностей.
Выбор ERP системы
Выбор ERP системы часто делается, исходя из стратегии или как реакция на конкуренцию. Если основные конкуренты фирмы внедрили ERP систему, то отказ от внедрения такой системы может стать самым большим риском. В этом случае конкурент сможет предложить улучшенное обслуживание клиентам благодаря таким возможностям, как «доступно по обещанию», как мы видели на примере Quantum Computer. При этом фирма рискует столкнуться с недостаточной конкурентоспособностью или потерять преимущество «первой внедрившей».
В некоторых случаях характеристики системы могут определить, будет или нет конкретная ERP система успешно работать. Например, многие традиционные системы были специально спроектированы так, чтобы соответствовать требованиям большого объема операций. Если новая система не соответствует требованиям, предъявляемым к ней в этой части, она успешно работать не сможет. Такие фирмы, как FoxMeyer; обанкротились из-за неспособности ERP системы справляться с необходимым объемом входных данных. Например, Радосевич (Radosevich 1998) заметил, что одной из причин провала внедрения ERP системы, названных FoxMeyer, была способность системы обрабатывать только 10 ООО элементов строки счета за вечер, хотя необходимо было обработать 420 000.
Проектирование ERP системы
Возможно, самый важный аспект проектирования ——это то, что фирма выбирает «конструктив» ERP системы, обеспечивающий наиболее подходящее соотношение затраты-вы годы. Каковы некоторые потенциальные причины выбора не самого оптимального «конструктива»? Во-первых, его выбор ——это процесс политический. Здесь как следствие политического процесса есть победители и проигравшие. Во-вторых, в некоторых ситуациях решения относительно «конструктива», которые должны быть приняты ответственными за процессы или менеджментом, принимают члены проектной команды. В результате, процессы не работают должным образом или плохо стыкуются с другими процессами. В-третьих, сложно или невозможно точно определить затраты и результаты, что усложняет выбор. В-четвертых, на этапе проектирования служащие начинают понимать, насколько изменится состав и обязанности персонала, и могут озаботиться этими изменениями. Например, один проект был остановлен, так как «этот проект изменил бы работу людей и сократил бы персонал в два раза. Самым простым решением было остановить проект, так как у людей просто не хватило мужества» (Stein 1997b).
Внедрение ERP системы
Два самых больших бизнес-риска состоят в том, что внедрение займет больше времени, и будет стоить больше, чем предполагалось. Например, объясняя тот факт, что доходы были на 10% меньше плана, служащие Hershey заметили, что сроки внедрения SAP-Siebel- Manugistics превысили плановые на три месяца (Branch 1999). Из-за задержки были нарушены прием заказов и дистрибуция. Подразделением правительства США были названы несколько факторов неудачи внедрения SAR включая перерасход средств (Stein 1997b).
После запуска системы
Если система после запуска не работает должным образом, могут возникнуть проблемы как с клиентами, так и с поставщиками. Например, как сказал Коч (Koch 1999): «Клиенты получали не то количество или не ту продукцию». Фирмам необходимо как можно быстрее решать такого рода проблемы, характерные для стабилизационного периода. В противном случае фирма может потерять клиентов и поставщиков или столкнуться с увеличением расходов на доставку задержанных заказов.
Обучение
При обучении пользователи должны получать информацию о процессах и системе. Хотя обучение часто недооценивают, оно может повлечь за собой ряд других бизнес-рисков (слишком раннее, слишком позднее, недостаточно детальное обучение и т. д.); см. плаву 13.
Организационные риски
Организационные риски связаны с людьми, структурой организации и средой, в которой система выбирается и внедряется.
Принятие решение внедрять
или не внедрять ERP систему
Возможно, самый большой риск связан с решением, внедрять или не внедрять ERP систему. Один из самых важных вопросов ——это участие в решении этого вопроса топ-менеджмента. Некоторые исследователи (например, King and Konsynski 1993) говорили о важности и преимуществах поддержки решения топ-менеджментом, если не о принятии им этого решения. Без заинтересованности топ-менеджмента может не оказаться ни достаточных ресурсов для реализации проек-
та, ни необходимого одобрения изменений в процессах. Один из основных факторов неудачного внедрения SAP федеральным правительством США был «недостаток поддержки руководства» (Stein 1997а).
Кроме того, при внедрении ERP систем необходимо заручиться поддержкой не только топ-менеджмента, отвечающего за информационные услуги, но и менеджеров, отвечающих за основные функциональные области. Их поддержка необходима в связи с высокой степенью возможности изменения в процессах. Как мы видели на примере Microsoft, корпорация имела опыт двух неудачных внедрений ERP систем. Успешным внедрение стало только тоща, когда получило поддержку финансового топ-менеджмента.
Однако даже недостаток поддержки со стороны топ-менеджмента не всегда приводит к неудаче. Например, компания Siemens Power, очевидно, не имела поддержки топ-менеджмента (Hirt and Swanson 1998). Однако проект был завершен вовремя и оказался рентабельным, и сейчас система широко используется.
Выбор ERP системы
Этот этап жизненного цикла ERP системы включает некоторые аспекты, относящиеся к «людям»,——например, правильный выбор консультанта. Хотя существует несколько переменных, которые могут повлиять на выбор консультанта, возможна доминирующая переменная ——это предшествующий опыт работы с консультантами. Однако, как видно на примере компании Siemens Power (Hirt and Swanson 1998), предшествующий опыт ——не единственная переменная. Компания Siemens запросила информацию о ценах у IBM, HP и Siemens Nixdorf (SNI, компания, принадлежащая Siemens). Как сказал один из менеджеров компьютерных информационных систем компании Siemens:
Не думаю, что мы получили бы конкурентоспособную цену от пяти крупнейших компаний. Они бы нами не заинтересовались... Но с IBM у нас хорошие отношения, и мы получили от этой компании подходящее предложение. Мы не приняли его, так как я думал, что у них в команде, которая будет здесь работать, нет человека, который имел бы производственный опыт, который я бы видел, ... да и цена была выше, чем цена, предложенная SNI. Поэтому, в конечном итоге, мы выбрали SNI.
Таким образом, Siemens Power выбрала компанию Siemens, минимизируя риск, связанный с привлечением сторонних производителей.
Проектирование и внедрение ERP системы
Системы планирования ресурсов предприятий требуют, чтобы модели организации были встроены в ПО. Эти модели ERP системы влияют на информационные потоки и, следовательно, могут изменить реальную структуру организации. Например, когда каждое подразделение становится или центром затрат, или центром прибыли (Bashein и др. 1997), становится доступной информация для оценки расходов и прибыли, чего не было раньше. Изменение доступности информации может привести к изменению отношений в организации.
Кроме того, как было сказано при обсуждении реинжиниринга «с большой буквы», фирмы часто меняют ПО для удовлетворения своих требований. Однако это может быть дорого и увеличить время внедрения. Например, компания Automated Packaging Systems (APS) отказалась от своей ERP системы, так как внедрение закончилось на год позже. Как сказал Зирега (Zerega 1998): «Задержка произошла из-за большого числа разработок, необходимых производителю для того, чтобы его ПО соответствовало рабочим процессам в APS».
Ранее мы говорили о том, что реинжиниринг «с маленькой буквы» зачастую сопровождается изменениями в процессах фирмы для того, чтобы соответствовать ПО. Это, в свою очередь, может привести к изменениям в организации и последующим изменениям во властных полномочиях внутри организации. Одной фирме, чтобы внедрить свою ERP систему, пришлось изменить у себя систему компенсационных выплат. Такие изменения, в целом, являются непредвиденными, и их трудно определить до внедрения.
После запуска системы
Аспекты корпоративной культуры относятся к самому важному организационному риску, связанному с запуском системы. Если ERP система не соответствует корпоративной культуре, она может быть отвергнута. Сама по себе технология планирования ресурсов предприятий не способна изменить корпоративную культуру; необходимы также значительные усилия со стороны менеджмента. Например, участник конференции Томас Девенпорт заметил:
Фирмы предполагают, что система SAP более или менее самостоятельно изменит культуру организации. Если бы компания SAP твердо заявила, что ни один пакет программного обеспечения не может изменить культуру без сотасованных действий менеджеров,
то мн, возможно, имели бы более высокий процент успешных внедрений. Возможно, компания уже заявляет об этом, но многие ее клиенты этого не понимают. (CIO1996)
Обучение и персонал
Как было замечено ранее, при использовании ERP систем ввод данных происходит ближе к источнику информации. В некоторых случаях это означает, что данные будут вводить служащие, не знакомые с этой задачей. Например, при использовании ERP системы ввод данных может осуществляться персоналом погрузочной площадки. Но если эти люди не знают, как пользоваться системой, задача выполнена не будет. Следовательно, особенное внимание должно быть уделено тому, чтобы служащие получили достаточное образование для правильного использования системы.
Однако основной организационный риск, связанный с обучением и персоналом, в том, что может не оказаться адекватно обученных людей после внедрения системы. Например, как отметил Ферранти (Ferranti 1998): «Если проект терпит неудачу, то распространенная причина этого состоит в том, что основной проектный персонал переманивается конкурентами компании, а управлять внедрением остаются люди, не знакомые с ним». Таким образом, необходимо обеспечить соответствующие карьерные возможности для проектной команды с тем, чтобы эти люди после внедрения системы продолжили работать на компанию.
Резюме
В данной главе, с одной стороны, представлена модель классификации видов рисков (технические, связанные с бизнесом и организационные), а, с другой стороны, — жизненный цикл ERP системы. Анализ исследования показал, что самые большие риски — организационные, затем идут бизнес-риски и технические риски. Остальная часть главы посвящена рассмотрению видов рисков в каждой категории, классифицированных по этапам всего жизненного цикла системы.
Литература
Austin, R” and Cotteleer, М. (1999). «Current Issues in IT: Enterprise Resource Planning». Unpublished presentation, October.
Bashein, В., Markus, L, and Finley, J. (1997). Safety Nets: Secrets of Effective Information Technology Controls. Morristown, NJ: Financial Executives Research Foundation：
Branch, S. (1999). «Hershey to Miss Earnings Estimates by as Much as 10%». Wall Street Journal, September 14, p. B12.
CIO (1996). «SAP Key Roles», (www.cio.com/forums/061596_sap_roles.html).
Cotteleer, M., Austin, R., and Nolan, R. (1998). «Cisco Sistems, Inc., Implementing ERP». report no. 9-699-022, Harvard Business School, Cambridge, MA.
Ferranti, M. (1998). «Debunking ERP Misconceptions». InfoWorld, August 17, p. 46.
Hirt, S., and Swanson, E. B. (1998). «Adopting SAP at Siemens Power Company». Paper presented at the International Conference on Information Systems (Helsinki), December.
Jesitus, J. (1997). «Broken Promises». Industry Week, November, (www.industry- week.com).
King, J., and Konsynski, B. (1993). «Singapore TradeNet (A): A Tale of One City». Report no. 9-191-009, Harvard Business School, Cambridge, MA.
Koch, C. (1999). «The Most Important Team in History». CIO Magazine, October 15.
Radosevich, L. (1998). «Bankrupt Drug Company Sues SAP». InfoWorld, August 27, (www.infoworld.com).
Stein,工(1997a). «IT Stalls at Xerox and Perrier». Information Week, March 31, p.20.
Stein, I (1997b). «Federal Site Drops SAP». Information Week, December 22, p.36.
Zerega, B. (1998). «Customer Information Center Supports Front Une». InfoWorld, August 10, p.58.
Сддержанме
Часть первая. Предисловие и вводная информация.5
Введение5
Системы и технологическая подоплека.17
Часть вторая. ERP системы*29
Основы ERP систем 29
Приложение 3-1. Geneva Steel: изменение работы бизнеса 43
Ввод данных в ERP системах .56
Возможность вывода данных в ERP системах 69
Приложение 5-1. Виртуальное хранилище данных компании Quantum78
Реинжиниринг; «запускаемый технологией»,, против реинжиниринга «с чистого листа».83
Часть третья. Жизненный цикл ERP систем 99
Принятие решения о внедрении ERP системы99
Приложение 7-1. Выбор ERP системы … собственная или готовая? 113
Выбор ERP системы 115
Приложение 8-1. Chesapeake Display&Packaging129
Приложение 8-2. Исследование, проведенное одним финансовым директором .131
Проектирование ERP систем: что нужно менять - бизнес-процессы или программное обеспечение
ERP систем?.132
Приложение 9-1. Внедрение системы SAP корпорацией Microsoft .148
Проектирование ERP систем: выбор
стандартных моделей, объектов и процессов ........161
Внедрение ERP систем 173
Приложение 11-1. Quantum I: требования, выбор системы и метод внедрения ................ 187
Приложение 11-2. Quantum II： внедрение «сразу» ... .192
Приложение 11-3. Quantum III: сотрудничество и конкуренция 197
Жизнь после запуска .198
Приложение 12-1. Изучение случая компании XYZ.
Как следует оценить ERP проект? .211
Приложение 12-2. Список контрольных вопросов компании Deloitte Consulting для периода после внедрения ERP системы .212
Обучение .214
Часть четвертая. Электронная коммерция и риски .221 14. ERP системы и электронная коммерция 221
Приложение 14-1. Использование ERP системы
OneWorld компании J.D. Edwards в Leventhal School университета Южной Калифорнии: интервью
с профессором Лесом Потером 235
Риски, связанные с ERP системами .242
Дэниел О'Лири
ERP системы.Современное планированиеи управление ресурсамипредприятия.
Выбор, внедрение, эксплуатация
Ответственный за выпуск Н.Г. ВладимироваНаучный редактор С.Б. АвринПеревод Ю.И. ВодяновойВерстка Н.В. МолокановаКорректор Д.Ю. Федосов
Учредитель:
Консультационно-финансовый центр «Актион»
ООО «Вершина»
127051, Москва, В.Сухаревск將访 пер,, 2/24Тел./Факс (095) 967-86-25, -26, -27www.glavbukh.ru
Подписано в печать 00.05.2004 г.
Бумага офсетная. Формат 70x108/16. Гарнитура «Прагматика»Печать офсетная. Печ. л. 17. Тираж 3000 экз. Заказ № 41301
Отпечатано с готовых диапозитивов.ООО ИД «Медиа-Пресса»п Москва, ул. Правды, д,24
Цена свободная
ОБ АВТОРЕ:
Дэниел О'Лири - профессор Высшей бизнес-школы Университета Южной Каролины, автор более 120 статей, опубликованных в научных ■ практических журналах по информационным технологиям ■ менеджменту Имеет докторскую степень Университета Case Western Reserve ■ MBA Мичиганского университета
Современный бизнес уже достаточно трудно представить себе без автоматизированных систем планирования и управления ресурсами предприятия (ERP) В то же время до сих пор открытыми остаются такие вопросы, как:
Какие преимущества дает компании внедрение такой системы? • Как выбрать, спроектировать, внедрить и настроить систему, оптимальную для бизнеса компании?
Требует ли переход к использованию ERP системы комплексного реинжиниринга бизнес-процессов?
Какие риски ожидают компанию до, в момент и после внедрения системы?
Настоящая книга является компасом в мире ERP систем. Автор дает краткий обзор систем, представленных на рынке, проводит экскурс в принципы их функционирования, описывает действия компании на каждом этапе жизненного цикла этих систем и заканчивает ассоциированными рисками, формируя полную картину современного планирования и управления ресурсами предприятия. Несомненный интерес представляют примеры использования ERP систем в компаниях различных отраслей экономики.
* В 2000 г. от компании Informix Corp, отделилась компания Informix Software, которая, собственно, и занималась разработкой СУБД, а в 2001 г она была приобретена корпорацией IBM и в настоящее время входит в ее подразделение Data Management Division (прим. науч, редактора).
* В 2000 к BAAN была приобретена компанией Invensys (прим.науч, редактора).
** Базируется на данных, опубликованных на ресурсах eddy.media.Utah.edи и www.geneva.com, а также обсуждениях в «Истории компании Geneva Steel» (см. www.geneva.com) (прим, автора).
** По материалам обсуждения компании Geneva Steel (www.geneva.com)) (прим, автора).
По материалам ресурса www.steelnet.org (прим, автора).
** В данном и последующих параграфах этой главы мы ссылаемся на компанию Timberjack, которая обсуждается в книге Романова, Кейла и МакФарлена (Romanov, Keil, and McFarlen 1998) fприм, автора).
* Материал данного примера был переписан, реорганизован, сокращен и объединен на основании материала следующих источников: Data Warehousing Institute, «ВР Winners,» (www.dw-institute.com/), 1998; J* Keerstetter, «Quantum Taps Oracle for Global Inventory System,» PC Week Online, June 27,1996; «Oracle at Work with Quantum Corporation,» (www.oracle.com); «1996 Annual Report,» (www.uk.ora- cle.com/), 1996; L. Radosevich, «Quantums Leap,» CIO Magazine, February 15,1997. (прим, автора).
** Фирмы или частные лица, занимающиеся продажей товаров с отчислением производителям определенного процента от доходов (прим. науч, редактора).
*** Hypertext Markup Language — язык гипертекстовой разметки, широко применяемый для создания web-страниц (прим. науч, редактора).
ERP СИСТЕМЫ
Дэниел О Лири
Современное планирование и управление ресурсами
网◎白凶/鹿%闾/%夕
Дэниел О'Лири
Enterprise Resource Planning Systems
Systems, Life Cycle,Electronic Commerce, and Risk
DANIEL E. О IE ARY
University of Southern California
ERP СИСТЕМЫ
Современное планирование и управление ресурсами предприятия Выбор, внедрение, эксплуатация
4
ВЕРШИНА
Москва 2004
scan: The Stainless Steel Cat
УДК 658.011.56 66К 65.290-2с51
0-11
This book is in copyright. Subject to statutory exception and to the provisionsof relevant collective licensing agreements, no reproduction of any part may take placewithout the written permission of Cambridge University Press.
Настоящее издание охраняется законом об авторских правах.
В соответствии с установленными исключениями и условиями соответствующихколлективных лицензионных договоров репродукция любой из частей изданияне возможна без письменного разрешения Cambridge University Press.
Перевод с англ. Ю.И. ВодяновойНаучный редактор С. Б. Аврин
О^ири, Дэниел
0-11 ERP системы. Современное планирование и управление ресурсами предприятия. Выбор, внедрение, эксплуатация/Дэниел О'Лири; [Пер. с англ. Ю.И. Водяновой]. - М.: ООО «Вершина», 2004.- 272 с.
ISBN 0-521-79152-9 (англ.)
ISBN 5-94696-067-9
Агентство С/Р РГБ.
Современный бизнес уже достаточно трудно представить себе без автоматизированных систем планирования и управления ресурсами предприятия (ERP). В то же время до сих пор открытыми остаются следующие вопросы: какие преимущества дает компании внедрение такой системы; как выбрать, спроектировать, внедрить и настроить систему, оптимальную для бизнеса компании; требует ли переход к использованию ERP системы комплексного реинжиниринга бизнес-процессов; какие риски ожидают компанию до, в момент и после внедрения системы?
Настоящая книга является компасом в мире ERP систем. Автор дает краткий обзор систем, представленных на рынке, проводит экскурс в принципы их функционирования, описывает действия компании на каждом этапе жизненного цикла этих систем и заканчивает ассоциированными рисками, формируя полную картину современного планирования и управления ресурсами предприятия. Несомненный интерес представляют примеры использования ERP систем в компаниях различных отраслей экономики.
Книга рассчитана на широкий круг специалистов в области информационных технологий, консультантов в области управления, руководителей компаний и студентов программ МВА.
ISBN 0-521-79152-9 (англ.)© Daniel Е. O'Leary 2000
ISBN 5-94696-067-9© ООО «Вершина», 2004
Published by the Press Syndicate of the University of Cambridge, 2000, 2002