Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Commerce, and Risk [1 ed.] 9780521791526, 0521791529, 5946960679

Citation preview

Enterprise Resource Planning Systems Systems, Life Cycle, Electronic Commerce, and Risk

DANIEL E. O'LEARY University of Southern California

Дэниел  О'Лири

ERP  СИСТЕМЫ Современное планирование и управление ресурсами предприятия Выбор, внедрение, эксплуатация

/is

ВЕРШИНА

Москва 2004

scan:  The  Stainless  Steel  Cat

УДК 658.011.56 ББК65.290-2с51 0-11 This book is in copyright.  Subject to statutory exception and to the provisions of relevant collective licensing agreements,  no reproduction of any part may take place without the written  permission  of Cambridge University Press. Настоящее издание охраняется законом  об авторских правах. В  соответствии с установленными  исключениями  и условиями  соответствующих коллективных лицензионных договоров  репродукция любой  из частей  издания не возможна без письменного разрешения Cambridge  University Press.

Перевод с англ.  Ю-И.  Водяновой Научный редактор  С.Б.Аврин

0 - 1 1 

О'Лири, Дэниел ERP  системы.  Современное  планирование  и  управление ресурсами  предприятия.  Выбор,  внедрение,  эксплуатация/Дэниел О'Лири; [Пер. с англ.  Ю.И. Водяновой]. - М.: 0 0 0 «Вершина», 2004. 272 с. ISBN 0-521-79152-9 (англ.) ISBN 5-94696-067-9 Агентство CIP РГБ. Современный  бизнес  уже  достаточно  трудно  представить  себе  без автоматизированных систем планирования и управления ресурсами предприятия  (ERP).  В то же  время до  сих  пор  открытыми  остаются  следующие вопросы:  какие  преимущества  дает  компании  внедрение  такой  системы; как выбрать,  спроектировать,  внедрить и настроить систему,  оптимальную для  бизнеса компании;  требует ли  переход к использованию  ERP системы комплексного  реинжиниринга  бизнес-процессов;  какие  риски  ожидают компанию до,  в момент и после внедрения системы? Настоящая  книга  является  компасом  в  мире  ERP систем.  Автор дает краткий обзор систем, представленных на рынке, проводит экскурс в принципы их функционирования, описывает действия компании на каждом этапе жизненного цикла этих систем и заканчивает ассоциированными рисками,  формируя  полную  картину  современного  планирования  и  управления ресурсами  предприятия.  Несомненный  интерес  представляют  примеры использования  ERP систем  в  компаниях различных отраслей экономики. Книга рассчитана на широкий круг специалистов в области информационных технологий,  консультантов  в  области управления,  руководителей компаний и студентов программ МВА.

ISBN 0-521-79152-9 (англ.)  ISBN 5-94696-067-9 

©  Daniel E. O'teary 2000 ©  ООО «Вершина», 2004

Published by the Press Syndicate of the University of Cambridge, 2000, 2002

Часть  первая ПРЕДИСЛОВИЕ И ВВОДНАЯ ИНФОРМАЦИЯ 1 ВВЕДЕНИЕ Этой главой начинается  наш  разговор о системах планирования ресурсов  предприятий (ERP системах),  и  в  ней  мы  остановимся  на следующих  вопросах: •  Зачем  изучать  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,  имеет доступ  к множеству лучших практик.  Более того,  постоянно добавляют-

ERP  СИСТЕМЫ

ся  новые примеры  ведения  бизнеса.  Как только  новые лучшие практики  найдены  и  введены  в  конкретные  приложения,  они  становятся доступными для включения в новые версии системы R/3; как только  новые  версии  становятся  доступными,  другие  фирмы  устанавливают  их.  Следовательно,  существует  цикл  поиска  новых  лучших практик,  ввода их в ПО и распространения их среди новых пользователей. Следовательно,  фирмы  должны  задавать  следующие  вопросы: • Какие  бизнес-процессы  дают  нам  преимущества  в  конкурентной борьбе? • Какие  новые  процессы  могут дать  нам  преимущества  в  конкурентной  борьбе? • Откуда  нам  известно,  что  в данных  процессах есть что-то  уникальное? • Сколь  ценен  этот  процесс  по  сравнению  с  рядом  широко  доступных  процессов? •  Каковы будут затраты для этой лучшей практики по отношению к конкурирующим? ERP  системы  дали  клиент-серверным  технологиям  их  первый корпоративный продукт.  В начале 90-х гг.  модель клиент-сервер стала доступной технологией,  имевшей  много преимуществ по сравнению с существующими решениями на базе мейнфреймов.  К сожалению, лишь ограниченное число программных продуктов было доступно для использования этих преимуществ. Системы планирования ресурсов  предприятия  изменили  ситуацию,  став  одними  из  первых главных  корпоративных  приложений,  работающими  в  архитектуре клиент-сервер. ERP  системы  изменили  природу  подразделений  информационных  систем.  Изначально,  работа  подразделений  информационных систем  заключалась  в  разработке,  развитии  и  внедрении  ПО.  В  настоящее время благодаря  ERP системам функции  разработки  и  развития  выводятся  за  пределы  предприятия.  Системы  планирования ресурсов  предприятий  удовлетворяют  большую  часть  потребностей фирмы  в  ПО.  Это  изменяет  основную  природу  подразделений  информационных систем,  и,  в то  время,  как  раньше требовались системные аналитики и программисты, теперь решающим является знание существующих пакетов  ПО. Изменились  не  только  требования,  но  и  стал  более  мобильным персонал  этих  подразделений.  Изначально,  персонал,  обслуживающий  информационные  системы,  имел  представление  только  о  конкретных традиционных  приложениях,  используемых данной  фирмой.

8

ЧАСТЬ ПЕРВАЯ. ПРЕДИСЛОВИЕ И ВВОДНАЯ ИНФОРМАЦИЯ

С  появлением  ERP  систем  ситуация  меняется,  и  знания  могут  быть использованы  не только  в  одной  фирме.  Знания  почти  о  любом  ERP пакете могут использоваться не только в одной организации,  но и во всем мире. Таким образом, так как использование пакетов ПО класса ERP возрастает,  персонал,  обслуживающий  информационные системы,  мобилен более, чем когда-либо. Кроме  того,  такая  мобильность  изменяет  консалтинговый  бизнес,  поддерживающий программные пакеты  ERP. 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  млн.  дол-

ERP  СИСТЕМЫ

ларов  и  Computron  —  17  млн.  долларов.  Общая  прибыль составила 319 млн. долларов. В 1998 г. рынок лицензирования / поддержки составил 17,2 млрд. долларов, а в 2000 г. доходы ожидаются в размере 24,3  млрд. долларов  (PricewaterhouseCoopers  1999).  Рыночный  рост систем класса ERP был огромным.

Как ERP системы создают ценность? Традиционные  информационные  системы  изначально  были функциональной основой для множества организаций или функциональных сфер, но не могли объединять их в случае их географической распределенности. Одну и ту же информацию собирали многократно и во многих местах,  и она была недоступна в реальном времени.  Рабочие  места и  процессы  были узко специализированы  в соответствии с разделением труда и промышленной революцией.  В результате  некоторая  информация  никогда  не  выходила  за  пределы  отдельных  подразделений  корпораций.  Определение  процессов  и  работ было  направлено  на  то,  чтобы  информация  удовлетворяла  локальным требованиям.  Когда же информация  становилась «глобальной», информационные отчеты об одних и тех же событиях часто были разными.  Таким  образом,  налицо  была  информационная  асимметрия между различными локальными и функциональными группами и топменеджментом. Системы  планирования  ресурсов  предприятий  предоставляют фирмам  модели обработки деловых операций,  которые интегрированы с другими видами их деятельности, такими как производственное планирование и управление человеческими  ресурсами.  Осуществляя  стандартные  процессы  компании  и  обеспечивая  ее  единой базой данных (БД), охватывающей все ее виды деятельности и места расположения, ERP системы обеспечивают интеграцию ее многочисленных  географически  разделенных  подразделений  и  функциональных областей.  В результате,  ERP системы привели к улучшению возможностей принятия решений, которые проявляются в широком ряде показателей, таких как сокращение запасов (сырье, полуфабрикаты  и  готовая  продукция),  сокращение  штатов,  ускорение  закрытия финансового  процесса  и  т.  д.  Таким  образом,  ERP  системы  могут быть  использованы  для  того,  чтобы  помочь  фирмам  создать  ценность.  В частности,  ERP системы способствуют созданию ценности, изменяя  основную  природу  организаций  множеством  различных способов.

10

ЧАСТЬ  ПЕРВАЯ.  ПРЕДИСЛОВИЕ  И  ВВОДНАЯ  ИНФОРМАЦИЯ

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

ERP системы используют «лучшие практики» Системы  планирования  ресурсов  предприятий  вобрали  в  себя более тысячи лучших способов организации бизнес-процессов. Эти лучшие  практики  могут  быть  использованы  для  улучшения  работы фирм.  Выбор и  внедрение ERP систем требует внедрения таких лучших практик.

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

ERP системы устраняют информационную асимметрию Системы  планирования  ресурсов  предприятий  складывают  всю информацию  в одну  и ту же  основную  БД,  устраняя  многочисленные информационные несоответствия. Это приводит к нескольким результатам.  Во-первых,  обеспечивается  повышение  контроля.  Как  сказал один из пользователей (Brownlee  1996,  с.  R17):  «Если ты  не выполняешь свою работу,  я вижу, что что-то не было сделано».  Во-вторых, открывается  доступ  к  информации  для  тех,  кому  она  нужна;  в  идеале, обеспечивается  улучшенная  информация  для  принятия  решений. В-третьих,  информация  перестает  быть  предметом  посредничества, так как она становится доступной и для  руководства,  и для служащих компании.  В-четвертых,  организация  может стать  «плоской»:  так  как

11

ERP СИСТЕМЫ

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

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

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

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

ERP системы способствуют взаимодействию и сотрудничеству между организациями ЕРРсистема обеспечивает информационную  магистраль для  организации взаимодействия и сотрудничества с другими организаци-

12

ЧАСТЬ ПЕРВАЯ.  ПРЕДИСЛОВИЕ И  ВВОДНАЯ  ИНФОРМАЦИЯ

ями. Фирмы все больше и больше открывают партнерам свои БД для облегчения  снабжения  и  других  видов  деятельности.  Чтобы  данная система работала, необходим единый архив, которым могут пользоваться  партнеры;  и  ERP  системы  могут быть  использованы  для  содействия таким обменам.

Какова цель этой книги, и какие проблемы затронуты в ней? Цель этой книги —  изучить некоторые наиболее важные и интересные  проблемы,  примеры  и  идеи,  относящиеся  к  ERP системам. Однако эта книга — не энциклопедия по ERP системам. В ней мы фокусируемся  на  тех  проблемах,  которые  важны  для  консультантов  и менеджеров.  Мы  также  останавливаемся  на  тех  понятиях,  которые более специфичны для ERP систем, чем для ПО в целом.  Например, хотя проектный менеджмент важен для внедрения любой ERP системы, он остается все же проектным менеджментом,  и большое количество  материалов  по  проектному  менеджменту  информационных систем доступно в других источниках. В данной книге мы не останавливаемся на практических проблемах, так как эти проблемы варьируются от одного программного продукта к другому,  и данную информацию  можно  получить  из  ряда  других  источников.  Например,  подробный анализ системы SAP можно найти в ASAP (1996) и Curran and Keller  (1998).  В  этой  книге  мы  редко  останавливаемся  на  деталях, связанных с  отдельными  ERP  системами,  хотя  конкретные  системы иногда используются для иллюстрации определенных концепций.

Каково содержание этой книги? В этой книге мы останавливаемся на пяти основных аспектах ERP систем: (1) базовая информация (глава 2), (2) системы и»их возможности (главы 3-6), (3) жизненный цикл ERP систем (главы 7-13), (4) электронная коммерция (глава 14), (5) риски (глава 15).

Базовая информация Чтобы  управлять  ERP  системами,  необходимы  большой  объем информации и знание других технологий, включая клиент-серверные

13

ERP  СИСТЕМЫ

технологии, сети, системы управления реляционными БД (и хранилища  данных),  концепции  ПО  (включая  готовое  и  традиционное  ПО), концепции  анализа  требований  (например,  моделирование  «как есть») и реинжиниринг.

Системы и их возможности Анализ ERP систем и их возможностей начинается с производителей ERP систем и их партнеров.  Рассматриваются  некоторые модули двух ERP систем  и обсуждаются такие  вопросы,  как использование  ПО  от одного  производителя  или  выбор  подхода  «лучшие  из подобных».  Кроме того,  рассматриваются  модели  и  процессы,  лежащие в основе ERP приложений,  и дается  краткое описание того, как  работают  ERP  системы.  Затем  приводится  подробный  анализ ввода  и  вывода  данных  в  ERP  системах для  определения  потенциальных источников затрат на эти системы  и  пользы от них.  И,  наконец, рассматриваются достоинства и недостатки реинжиниринга «с чистого листа» по сравнению с реинжинирингом, «запускаемым ERP технологией».

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

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

14

ЧАСТЬ  ПЕРВАЯ.  ПРЕДИСЛОВИЕ  И  ВВОДНАЯ  ИНФОРМАЦИЯ

Риски Во введении мы остановились на достоинствах 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.

15

ERP  СИСТЕМЫ

В-третьих,  в  приложениях  дается  более  детальная  информация по  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, С (1998). «ERP is Changing Manufacturing Jobs».  InfoWorld, July 13. Curran, Т., 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,  С  (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.

*  С  октября  2003  года  фирмы,  известные  на  различных  национальных  и международных  рынках,  как  Deloitte  Touche  Tohmatsu  (Делойт  Туш  Томацу), Deloitte  &  Touche  (Делойт  и  Туш),  Deloitte  Consulting  (Делойт  Консалтинг), сохранив  свои  юридические  названия,  предоставляют  услуги  под  единым брэндом  Deloitte (прим.  науч.  редактора).

16

ЧАСТЬ  ПЕРВАЯ.  ПРЕДИСЛОВИЕ  И  ВВОДНАЯ  ИНФОРМАЦИЯ

2 СИСТЕМЫ  И  ТЕХНОЛОГИЧЕСКАЯ

ПОДОПЛЕКА

Цель данной главы — дать краткую вводную информацию по различным системам и технологиям, чтобы облегчить понимание вопросов,  связанных с  предметом  ERR  С  этой  целью  здесь  представлены основы обработки данных и работы в сети, баз данных, программного обеспечения, выбора ПО и реинжиниринга. Чтобы привязать материал данной главы непосредственно к ERP системам,  в рамках рассмотрения  каждой  категории  основная  информация  соотносится  с соответствующими аспектами ERP концепции (в частности,  на примере системы SAP).

Обработка  данных Первоначально  обработка  данных  на  предприятии  по  большей части базировалась на мейнфреймах. Однако примерно в 1993 г. (см. например,  Frye  1994)  более доступными  стали  версии  приложений для обработки данных предприятий в рамках модели клиент-сервер.

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

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

17

ERP  СИСТЕМЫ

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

18

ЧАСТЬ  ПЕРВАЯ.  ПРЕДИСЛОВИЕ  И  ВВОДНАЯ  ИНФОРМАЦИЯ

SAP и клиент-серверная архитектура Первый  продукт компании SAP (система  R/2,  разработанная для использования в среде мейнфреймов) был представлен в 1974 г. Клиент-серверное ПО компании SAP (R/3) было представлено в  1992 г.  в Европе и в 1993 г. в Северной Америке. ПО  R/3  может  быть  сконфигурировано  большим  числом  способов (ASAP  1996).  На одной стороне спектра — применение центральной системы для осуществления представления информации, исполнения приложений и сервисов, связанных с БД. На другой — использование  крупными  ERP системами трехзвенной  архитектуры  клиентсервер  с  отдельными  серверами  для  каждой  из  указанных  функций (ASAP  1996; Juergens  1999).

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

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

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

19

ERP  СИСТЕМЫ

токол  управления  передачей  (transmission  control  protocol  (TCP))  и Интернет-протокол (IP). Одними из многочисленных способов защиты информации являются использование межсетевых экранов* и шифрование.  Межсетевые экраны обеспечивают мероприятия по защите в сетях. Они усиливают защиту серверов,  контролируя  трафик.  Межсетевые  экраны обычно  размещают  между  локальной  сетью  корпорации  и  внешней сетью (например, Интернетом). Шифрование обеспечивает безопасность информации,  передаваемой  через  открытые  сети.  В  частности,  путем  шифрования  информация,  которую  можно  прочесть,  преобразуется  в  нечитаемую форму. При этом информационная безопасность может быть обеспечена путем шифрования данных таким образом, что к ним могут получить доступ только те,  кто обладает специальными  правами  и в силу этого  может  использовать  соответствующие  механизмы  дешифрирования.

Каналы связи, используемые SAP Если  ERP  система  работает  в  автономной  сети,  то  пропускная способность данной  сети  должна  быть достаточной  для  того,  чтобы соответствовать  потоку  деловых  операций  этой  системы.  Другими словами, сеть должна адаптироваться и к потоку операций в ERP, и к нагрузке, вызванной работой любых других приложений, использующих ту же самую сеть. Коммуникации внутри ERP системы обычно базируются на стандартных протоколах связи.  Например,  система  SAP  R/3 для  организации взаимодействия между клиентом и сервером использует протокол TCP/IP (ASAP 1996).

Два способа защиты, используемых SAP SAP  предлагает  несколько способов  защиты.  В данном  разделе говорится о маршрутизаторах SAP и шифровании (см. Juergens 1999). Маршрутизатор  SAP  —  это  ПО,  обеспечивающее  дополнительный уровень защиты.  Оно  обеспечивает соединения  SAP через межсетевой экран. Маршрутизатор SAP не заменяет межсетевые экраны, а используется в сочетании с ними.  Его задача — запретить или раз-

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

20

ЧАСТЬ  ПЕРВАЯ.  ПРЕДИСЛОВИЕ  И  ВВОДНАЯ  ИНФОРМАЦИЯ

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

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

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

Имя

Адрес

Рис.  2.2.  Плоский  файл

21

ERP  СИСТЕМЫ

Проблема  использования  «плоских  файлов»  состоит  в  том,  что может возникнуть избыток информации. Рассмотрим в качестве примера «плоский файл», созданный для сбора данных по продаже товаров, Например, нам нужно найти в БД информацию о том, кто совершил продажу, его адрес, номер карточки социального страхования и т. д. Однако, если тот же самый человек совершит другую продажу, в БД снова  будут записаны  те же данные,  что  приведет  к  избытку  информации.  Одним  из  средств  устранения  избыточной  информации является  использование реляционных БД,  где может быть использован единственный номер ссылки для сбора всей информации о том, кто совершил продажу.

Реляционные базы данных Реляционная  БД  —  это  набор  связанных  между  собой  таблиц (см. рис. 2.3). Например, вместо того чтобы фиксировать полный набор данных о покупателе (продавце) для каждого заказа, можно воспользоваться  только  номером  покупателя  (продавца).  Затем,  если нужна  более  детальная  информация,  можно  найти  ее  в  связанной таблице, используя этот номер.

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

22

lACTb  ПЕРВАЯ.  ПРЕДИСЛОВИЕ  И  ВВОДНАЯ  ИНФОРМАЦИЯ

Рис.  2,4.  Запись  о  продаже ровании того, сколько наименований товара будет в продаже, и других связанных вещей.

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

Программное обеспечение ERP системы — это,  в  конце  концов,  программные продукты,  и говоря об этих системах, необходимо затронуть такие вопросы, касающиеся ПО, как операционные системы, традиционные системы, готовое ПО, системы управления базами данных (СУБД) и существование различных версий ПО.

Операционные системы Системы  планирования  ресурсов  предприятий  были  спроектированы для работы со многими операционными системами, включая системы, базирующиеся на UNIX и Windows NT. Изначально, фактически все крупные  внедрения  ERP систем были сделаны  под UNIX.  Од-

23

ERP  СИСТЕМЫ

нако,  как сказано  в ASAP  (1996)  о  системе SAP  R/3,  для  представления  информации,  прикладных задач  и  БД могут использоваться свои операционные системы.

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

Готовое программное обеспечение Готовое  ПО  —  это  ПО,  разработанное  для  использования  во многих организациях.  Возможно,  самое известное готовое ПО было разработано  компанией  Microsoft.  Сейчас существует большое  число  готовых  программных  продуктов,  предназначенных  для  использования  на  персональных  компьютерах,  включая  такие  программы, как MS Word  и  MS  Excel.  В  последнее  время  на  предприятиях отчетливо видна тенденция  к использованию готового ПО,  и  ERP системы сейчас относят к этой категории продуктов. Готовое ПО создается с большим набором возможностей. Однако многие из них фактически не используются, поскольку каждая компания  выбирает из ряда возможностей только те,  что нужны именно ей. Одно  из  средств  удовлетворения  нужд  конкретного  предприятия  — настройка параметров ПО. Доступ к возможностям системы не требует ее обязательного перепрограммирования. Вместо этого для выбора  необходимых  возможностей  часто  используется  «установка  переключателей»  —  эквивалент  переключателей,  включающих  и  выключающих опции в программах. В  конечном счете,  использование  готового  ПО означает отказ от разработки  ПО  внутри  компании  и  передачу таких разработок на аутсорсинг (т.  е.  силами сторонних организаций).  Как результат,  «купить ERP систему значит больше, чем купить программное обеспечение. Вы покупаете у компании точку зрения» (Langdoc  1998).  Выбирая  ERP систему,  вы  передаете  большую  часть  обязанностей  по  содержанию  и развитию  своих  систем  ее  производителю.  Это  значит,  что  важным критерием выбора ПО может быть дальновидность его производителя.

24

ЧАСТЬ  ПЕРВАЯ.  ПРЕДИСЛОВИЕ  И  ВВОДНАЯ  ИНФОРМАЦИЯ

Система управления базами данных СУБД —  это  ПО,  разработанное для  облегчения  использования конкретных структур БД, например,  реляционных. СУБД необходимы не только потому, что в них сосредоточены данные, но и потому, что они обеспечивают доступ к данным.  Информация в виде отчетов извлекается из БД в результате запросов к ним. Это означает, что СУБД умеют формировать команды  запроса данных  (они  позволяют  пользователю задавать вопросы о данных)  и снабжены  генераторами отчетов,  позволяющими создавать отчеты о данных. Обычно  системы  класса  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),  СУБД интегрирована в саму систему посредством «базисных» компонентов.

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

* В 2000 г. от компании Informix Corp. отделилась компания Informix Software, которая, собственно, и занималась разработкой СУБД, а в 2001  г она была приобретена  корпорацией  IBM  и  в  настоящее  время  входит  в  ее  подразделение  Data Management  Division  (прим.  науч.  редактора). **  в  2002  г.,  по  данным  исследовательской  компании  IDC,  рыночные  доли здесь  были  следующими:  Oracle  —  39,4  %,  IBM  —  33,6%,  Microsoft  —  11,1%, Sybase  —  3,6%  (прим.  науч.  редактора).

25

ERP СИСТЕМЫ

ма  Windows  корпорации  Microsoft.  Она  была  выпущена  в  версиях Windows 3.1, Windows 95, Windows 98, Windows 2000 и Windows NT*. A со  времени  выхода  системы  SAP  R/3  было  несколько  версий  этого программного продукта, включая 3.0, 3.1,4.0, 4.5 и 4.6  . ПО  систем  планирования  ресурсов  предприятия  выпускается  в различных  версиях  в  связи  с тем,  что  происходит добавление  новых характеристик,  включаемых в него  в  процессе его  развития. Для  покупателей  ERP  систем  существуют  как  преимущества,  так  и  недостатки  использования  новых версий.  Среди  преимуществ — наличие новых характеристик  и  устранение  имевшихся  дефектов.  Среди  недостатков — возможная несовместимость различных версий ПО и затраты на модернизацию.

Выбор программного обеспечения  и анализ требований В данном разделе рассматриваются вопросы выбора ПО и дается анализ требований.

Выбор программного обеспечения: анализ затрат и выгод Выбор  ПО  не должен  быть случайным  процессом,  а должен  представлять собой результат тщательного учета всех факторов, которые могут  повлиять на  принятие  решения.  Кроме того,  рациональный  выбор, отдающий  предпочтение какому-то  программному пакету,  обычно подразумевает разновидность анализа экономической эффективности  или «возврата на инвестиции» (Return on Investment, ROI).  К сожалению, выгоды могут быть неявными (трудными для определения и прогнозирования), а некоторые расходы скрытыми. Фактически, расходы и выгоды невозможно  полностью  измерить,  пока  система  не  проработала  год или около того. В результате многие попытки анализировать готовое ПО оказываются бесполезными из-за недостатка достоверной информации.

«Как есть» и «Как должно быть» Существует по  крайней  мере две  модели  бизнес-процессов  организации:  модель «как есть»  используется для  моделирования теку* Автор не указал еще одну версию Windows —  Millenium.  Кроме того,  уже после подготовки оригинального издания книги была выпущена версия ХР этой операционной  системы  (прим.  науч.  редактора). ** С момента подготовки оригинального издания книги (2000 г.) SAP выпустила такие  новые  версии  системы,  как  R/3  Enterprise  и  mySAP  ERP  (прим.  науч.  редактора) .

26

ЧАСТЬ  ПЕРВАЯ.  ПРЕДИСЛОВИЕ  И  ВВОДНАЯ  ИНФОРМАЦИЯ

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

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

«Лучшие практики» против «ликвидации» Реинжиниринг бизнес-процессов, впервые рассмотренный Хэммером (Hammer 1990),  предполагал отказ от существующих процессов и создание процессов, которые соответствовали бы нуждам компании в свете передовых технологий. К сожалению, для фирм оказалось трудным отказаться от существующих процессов и работников. Когда же они все-таки решались на это, они не знали, чем нужно заменить существующие процессы или как разработать новые. Поскольку  «лучшие  практики»  представляли  собой  процессы, «проверенные  жизнью»,  они  быстро  нашли  признание  как средство выбора новых процессов. «Лучшие практики» — это те, что считаются наилучшими или просто лучшими способами реализации определенного бизнес-процесса. Одним  из  источников  лучших  практик  является  ERP  система. Обычно лучшие практики заложены в библиотеках процессов ERP систем, и при внедрении нужно лишь сделать соответствующий выбор. Как  правило,  ERP системы  содержат множество  лучших практик,  так что ПО может быть настроено (кастомизировано) для удовлетворения потребностей  каждой  компании-заказчика,  которая  устанавливает его.  Например,  система SAP R/3 содержит более  1  100 лучших практик. Благодаря наличию такого их числа, практически каждая реализация системы  является  индивидуальной,  поскольку набор отобранных лучших практик варьируется от внедрения к внедрению. Некоторые  консалтинговые  фирмы  имеют  свои  собственные  БД лучших  практик,  которые  используются  в  качестве  альтернативных  в процессе  поддержки  внедрения  ERP  систем.  Например,  компания

27

ERP СИСТЕМЫ

Price Waterhouse (1995) реализовала свою базу знаний лучших практик «Обзор знаний»  («Knowledge View»).  Подобные  БД лучших  практик являются частью того, что все чаще называют «управлением знаниями».

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

Литература ASAP [World Consultancy] (1996). Using SAP R/3. Indianapolis,  IN: Que. Frye,  С  (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 ClOs». PC Week, September 21, p. 88. Markoff,  J.  (1998).  «Oracle  Database  Takes  Aim  at  Windows».  New York  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.

28

Часть  вторая ERP СИСТЕМЫ 3

ОСНОВЫ  ERP  СИСТЕМ

Цель данной  главы  —  дать  некоторую  базовую  информацию  о ERP  системах.  Соответственно,  мы  обратимся  к  следующим  вопросам: •  Что такое  ERP система? •  Кто  производит ERP системы? • Кто является  партнерами производителей  ERP систем? •  Что  собой  представляют  некоторые  типовые  модули  ERP систем? •  Что значит,  когда  говорят «лучшие  из  подобных»? • Что такое дополнения  к ERP системам? • Что такое модели, объекты и процессы ERP систем? •  Как  работают  ERP  системы? Так как компания SAP сегодня доминирует на рынке ERP систем, я использую ее систему для иллюстрации некоторых общих понятий, связанных с ERP системами.

29

ERP  СИСТЕМЫ

Что такое ERP система? ERP системы  — это  компьютерные системы,  созданные для  обработки деловых операций организации и для содействия комплексному и  оперативному  (в  режиме  реального  времени)  планированию, производству  и  обслуживанию  клиентов.  В  частности,  ERP  системы имеют следующие характеристики: • это  готовое  ПО,  разработанное для  среды  клиент-сервер,  как традиционной, так и базирующейся на интернет-технологиях; • эти системы  интегрируют большинство бизнес-процессов; •  они  обрабатывают  большую  часть  деловых  операций  организации; • эти системы  используют БД всего  предприятия,  каждый образец данных в которой запоминается,  как правило, единожды; • они обеспечивают доступ к данным в режиме реального времени; •  в  некоторых случаях данные системы  позволяют интегрировать обработку деловых операций и действий по планированию (например,  производственное планирование). Более того,  ERP системы  все чаще  имеют такие дополнительные характеристики, как: •  поддержка  многочисленных  валют  и  языков  (что  очень  важно для  транснациональных  компаний); •  поддержка  конкретных отраслей  (например,  SAP  поддерживает  большое  число  отраслей,  включая  нефтяную  и  газовую  отрасли,  здравоохранение,  химическую  промышленность  и  банковское дело); • способность к настройке  (кастомизации)  без  программирования  (например,  установкой  «переключателей»).

Кто производит ERP системы? Часто ведущих производителей  ERP систем обобщенно называют BOPSE  по  первым  буквам  названий  компаний  (BAAN  ,  Oracle, PeopIeSoft  , SAP и J.D.  Edwards  ). Среди других фирм,  производя* В 2000 г. BAAN была приобретена компанией Invensys (прим.науч. редактора). "  Компания  PeopIeSoft  была  известна  в  основном  на  американском  рынке, но в  настоящее время  прилагает серьезные усилия для  завоевания  европейского рынка  (прим.  науч.  редактора). *"  В  2003  г.  J.D.  Edwards  была  поглощена  компанией  PeopIeSoft  (прим. науч.  редактора).

30

ЧАСТЬ  ВТОРАЯ.  ERP СИСТЕМЫ

щих ERP системы, такие как Great Plains, Lawson, Platinum, QAD и Ross and Solomon* (см., например, Keeling 1996; Kernsar and 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.oracte.com) Oracle —  второй  по  величине поставщик ПО в  мире.  Однако эта компания,  возможно,  больше известна благодаря своей СУБД,  а не ERP приложениям. Компания Oracle была создана в  1977 г.  в Соединенных Штатах.  Приложения для  рынка США были разработаны ею в 1989 г., а для международного рынка в 1993 г. В 1997 г. Oracle объявила о том, что она собирается работать на рынке конкретных отраслей (Greenberg  1997a) и улучшить характеристики своего ПО для международного  рынка (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 имеет репутацию компании, разрабатывающей продукт, который мо* Эти фирмы,  кроме Platinum,  на российском  рынке не представлены,  зато, наоборот, широкую известность приобрела датская фирма Navision со своими системами  Attain  и  Axapta.  После  ее  приобретения  в  2002  г.  компанией  Microsoft Navision  превратилась в ее  подразделение  Microsoft  Business Solution,  а соответствующие системы  получили  новое название:  Microsoft Business Solution-Navision и  Microsoft  Business  Solution-Axapta  (прим.  науч.  редактора).

31

ERP  СИСТЕМЫ

жет быть связан с другими  продуктами для создания системы,  способной  претендовать  на  титул  «лучшая  из  подобных».  Oracle  также позволяет  создавать  «доморощенное»  ПО*  (Holt  1998).  Кроме  того, возможно из-за того, что она в основном специализируется на СУБД, эта компания была первой,  предложившей такой продукт,  как хранилище данных, и начавшей интегрировать в свои продукты Интернет.

PeopIeSoft (www.peoptesoft.com) Компания  PeopIeSoft была основана  в  1987  г.  и  приобрела широкую известность в 1992 г. PeopIeSoft — третья по величине компания — производитель ERP систем. В 1997 г. ее доля на рынке составила 6%,  а прибыль компании  в  1998 г.  превысила  1,3 млрд. долларов (Bylinsky 1999). Система PeopIeSoft может обеспечить работу от 10 до 500 пользователей  (Keeling  1996). ERP  система  PeopIeSoft  стала  известной  из-за  предоставления широчайших  возможностей  планирования  человеческих  ресурсов (Kersnarand May 1999).  Во многих случаях фирмы выбирали какую-то иную  ERP  систему  из-за  всех остальных модулей  (например,  SAP)  и PeopIeSoft  для  планирования  человеческих  ресурсов.  В  некоторых случаях  благодаря  качеству  соответствующего  модуля  некоторые клиенты выбирали и 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 Cortese1997). SAP  известна  тем,  что  тратит  большую  часть  своих  доходов (обычно от 20% до 25%) на исследования и развитие. По имеющимся данным  система  SAP  R/3  имеет более  9  000  внедрений  в  более  чем *  Имеется  в  виду,  что  ПО,  созданное самим  пользователем,  может быть органично вписано  в ERP систему компании  {прим.  науч.  редактора). "  Системы,  приложения  и  продукты  по обработке данных (прим.  науч.  редак-

тора).

32

ЧАСТЬ  ВТОРАЯ.  ERP СИСТЕМЫ

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  систем.  Например,  она  была первой компанией, разрабатывающей версии своего ПО для конкретных  отраслей,  и  первой  действительно  международной  компанией. Кроме того,  она первенствовала в разработке хранилищ данных.

3.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  (а  вслед *  Класс  компьютерных  систем  компании  IBM  {прим.  науч.  редактора). **  Имеются  в  виду  консалтинговые услуги  (прим.  науч.  редактора).

33

ERP  СИСТЕМЫ

за ней и другими производителями  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% работают в самой SAP. В  настоящий  момент  среди  партнеров  компании  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, PeopIeSoft, BAAN и Lawson, приносят от одной трети до половины  общего дохода от консалтинга» фирм  «большой  пятерки»,  оказывающих профессиональные услуги. Консультанты  SAP  вообще  рассматривались  по-другому,  чем консультанты  консалтинговых фирм,  сотрудничающих с SAP.  Например, как отмечают Марч и Гарвин (March and Garvin 1996, с.7): «Нет ничего из того, что мы делаем, чего не могли бы сделать наши  партнеры.  Но  наши  консультанты  имеют  столь  же  глубокие знания, сколь их — широкие. Наши консультанты глубоко знают продукт и всегда будут немного опережать партнеров по своим способностям и требованиям, предъявляемым к ним». SAP  —  не  единственный  производитель,  широко  сотрудничающий с консалтинговыми фирмами. Например, как отмечается в Public Accounting  Report (1997),  каждая  фирма  профессиональных услуг — участница  «большой  шестерки»  (на  сегодняшний  день  «большой  пятерки») имеет консультантов, специализирующихся на программных продуктах BAAN и других пакетах.

34

ЧАСТЬ  ВТОРАЯ.  ERP СИСТЕМЫ

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

Модули SAP Система SAP R/3 содержит следующие прикладные модули (см., например, ASAP 1996, с. 74-8)*: •  AM** (fixed asset management — «Управление основными средствами»),  отвечающий  за  информацию  относительно  износа, страхования, основных фондов и т. д. •  СО (controlling — «Управление»),  включающий блоки «Учет центров  затрат»,  «Управление  себестоимостью»  и  «Функционально-стоимостной анализ» (activity-based costing, ABC). •  FI  (financial  accounting  —  «Финансы»),  включающий  блоки «Главная  книга»,  «Дебиторская  задолженность»,  «Кредиторская задолженность»  и  «Консолидация  в соответствии с законодательством» (legal consolidations). •  HR  (human  resources  —  «Кадры»),  включающий  блоки  «Управление персоналом»  и «Планирование и  развитие». •  MM  (materials  management  —  «Управление  материалами»), включающий блоки «Управление запасами»,  «Контроль счетовфактур»,  «Управление  складами». •  РМ (plant maintenance — «Обслуживание предприятия»), включающий блоки «Производственные и технические объекты», «Профилактическое обслуживание»,  «Управление техническим  обслуживанием», «Управление заказами на техническое обслуживание». •  РР (production  planning — «Производственное планирование»), включающий  блоки  «Операционное  планирование  и  планирование  продаж»,  «Материальное  планирование»  и  «Планирование мощностей». •  PS (project system  —  «Проектная  система»),  который  включает блоки  «Управление  проектами»  и  «Управление  бюджетом».

В  настоящее  время  компания  предпочитает  называть  их  компонентами {прим.  науч.  редактора). В  настоящее  время  этот  модуль  носит  название  АА  (asset  accounting  — Учет  основных  средств)  (прим.  науч.  редактора).

35

ERP СИСТЕМЫ

•  QM (quality management — «Управление качеством»),  включающий  блоки  «Сертификаты  качества»,  «Инспектирование», «Средства  планирования»  и  «Уведомление о  качестве». • SD (sales and distribution — «Продажи и дистрибуция»). Кроме  того,  в  системе  существуют  так  называемые  «общие» (cross-application) модули, которые могут быть использованы в системе R/3 повсеместно. Среди них — SAP business workflow (поддержка рабочих процессов) и SAP office (поддержка офисной работы).

Приложения компании Oracle Основные приложения компании Oracle делятся на три специфические  группы:  «Спрос»,  «Поставки»  и  «Финансы».  Блок  «Спрос» включает  модули  «Заказы»,  «Дебиторские  задолженности»  и  «Запасы».  В блок «Поставки» входят модули «Проектирование процессов», «Ведомость материалов»,  «Материальное  планирование»,  «Незавершенное производство» и «Закупки».  Блок «Финансы» включает модули  «Главная  книга»,  «Кредиторские  задолженности»  и  «Управление стоимостью». Существуют  дополнительные,  «наращивающие»  приложения. Так, блок «Спрос» может также включать приложения «Комиссионные с продаж» и «Компенсации, связанные с коммерческой деятельностью». Блок «Поставки» — приложения «Планирование цепочки поставок», «График поставщиков», «Производительность и качество». Блок «Финансы» — приложения «Основные средства»,  «Проектный учет» и «Финансовый  анализатор».  Наконец,  другие  приложения  включают модули;  «Кадры»,  «Платежная  ведомость»,  «Хранилище  данных»  и «Специализированные отчеты».

Что значит «Лучшие из подобных»? Обычно  фирмы  выбирают  для  внедрения  единственный  программный  пакет  ERR  Однако  некоторые  из  них  выбирают  подход «лучшие из подобных», пытаясь сочетать и совмещать модули, которые наиболее отвечают их потребностям.

Взаимозаменяемость Различные  модули  ERP систем  не  являются  взаимозаменяемыми. Более того, для большинства фирм BOPSE существует мало стимулов делать свое ПО взаимозаменяемым с ПО других фирм, не входящих в этот «клуб грандов». Кроме того, для большинства наиболее

36

ЧАСТЬ ВТОРАЯ. ERP СИСТЕМЫ

влиятельных фирм,  входящих  в  BOPSE,  еще  меньше  стимулов  делать свое  ПО  взаимозаменяемым  с  ПО  фирм,  имеющих меньшее  влияние в  этом  «клубе».  В  результате  мы  вряд  ли  увидим  в  ближайшем  будущем  взаимозаменяемые  модули  ERP  систем.

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

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

37

ERP  СИСТЕМЫ

модулей.  В-шестых,  если  различные  отделения  фирмы  используют разные решения в рамках подхода «лучшие из подобных», то единообразия  между  их системами  не  будет,  а,  значит,  не  будет  обеспечено одно из главных преимуществ ERP систем.  К сожалению,  как заметил Фиман (Freeman  1997, с.  61),  во многих случаях «затраты на стыковку специализированного  «производственного»  ПО  с  интегрированной ERP системой  намного  перевешивают  преимущества».

Дополнения к ERP системам Для  каждой  ERP  системы  разные  производители  разработали различные дополнения — дополнительное  ПО,  расширяющее их возможности.  Например, компания SAP поощряла создание различными независимыми  разработчиками  ПО,  стыкуемого  с  ее  ERP  системой. Такое  ПО  увеличивает  функциональные  возможности  SAP  R/3  и  позволяет  понять,  какие  новые  и  старые  функциональные  возможности представляют  интерес. Некоторые технологии, о которых не рассказывается в этой книге,  в том числе программы обеспечения связи приложений  (applica-

Рис. 3.1 Модель организационных структур системы R/3 (Источник: SAP)

38

ЧАСТЬ  ВТОРАЯ. ERP СИСТЕМЫ

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 описать каждое подразделение для целей моделирования оценки либо как центр затрат, либо как центр прибыр. К сожалению, это представление отличалось  от  существующей  организационной  модели,  и  Microsoft пришлось приспосабливаться к модели.

Объекты Саймон  (Simon  1985,  с. 10)  определил  объект как «интерфейс  ... между «внутренней» средой — содержанием и организацией самого

39

ERP  СИСТЕМЫ

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

Процессы Процессы — это потоки деятельности и информации,  необходимые для  выполнения  определенной  задачи  или  группы  задач.  Обычно организации должны выбирать процессы, соответствующие их потребностям, из набора процессов, содержащихся в ERP системе. Поскольку,  в  принципе,  существует  множество  способов  выполнения задачи или групп задач, каждый из процессов не является единственно возможным. А так как они не являются единственно возможными, ожидается,  что одни  процессы  будут  работать лучше,  чем другие.  В рамках  ERP  систем  существуют  многочисленные  процессы,  охватывающие  несколько функций. На  рисунке  3.2  изображен  процесс  управления  заказами  SAP (McAfee and Upton 1997). Этот процесс отображается в многочисленных  модулях  SAP,  интегрированных  между  собой.  В  традиционной функционально-ориентированной  системе,  напротив,  существовало бы,  по  меньшей  мере,  четыре  различные  системы  (товарооборот  и распределение,  производственное  планирование,  управление  материалами  и  финансы),  которые  не  были  бы  интегрированы.  И  обмен информацией между ними  производился бы  вручную,  если бы  вообще производился. Внедрение  процессов системами  планирования  ресурсов предприятий,  в конечном счете, требует многих решений,  которые обычно принимаются группой внедрения. Среди этих решений такие,  как, например,  кому  выдать  кредит  и  кому отказать,  или,  когда  предложить скидки  и  кто  их должен  получить.  Коч  (Koch  1999)  цитирует одного из членов группы внедрения  ERP системы: «Мы практически управляем  компанией.  Мы  принимаем  решения.  Еще  два  года  назад

40

ЧАСТЬ  ВТОРАЯ.  ERP СИСТЕМЫ

Рис.  3.2  Процесс  управления  заказами. было  бы  неслыханно,  чтобы  те,  кто  занимает  подобные должности, принимали бы такие решения, но сейчас люди хотят, чтобы мы управляли их подразделениями».

Как работают ERP системы? Чтобы  составить  общее  представление  о  работе  ERP  систем, рассмотрим систему компании SAP.  Прекрасный  пример находим у Эдмондсона и др. (Edmondson1997), который мы здесь и приводим. International Sneaker Company (ISC) — это некая гипотетическая американская компания, ведущая торговлю во всем мире; свой продукт она производит в Тайване. (1) Заказ. Торговый представитель компании ISC принимает заказ от розничного торговца в Бразилии. Вводя данные в свой персональный  компьютер,  этот  представитель  получает  доступ к модулю продаж системы R/3.  Система проверяет цену и скидки для данного розничного торговца,  а также его кредитную историю, чтобы убедиться в том, что фирма готова совершить продажу. (2) Наличие.  Затем  ПО  проверяет наличие товара.  Оно  находит, что половина заказа есть в  наличии  на складе  в Бразилии,  и эта  часть  заказа  может  быть  реализована  немедленно.  Сис-

41

ERP  СИСТЕМЫ

тема  R/З  выясняет также,  что другую  половину заказа  нужно будет доставить с предприятия компании ISC. (3) Производство.  Система R/З уведомляет склад о том,  что необходимо  доставить  розничному  торговцу  часть  его  заказа. Кроме того,  «производственное»  ПО  системы  R/З  планирует изготовление остальной  части заказа.  Счет распечатывается в Португалии. (4) Рабочая сила.  Во  время  планирования  производства система  R/З  отмечает  недостаток  рабочей  силы  для  выполнения заказа. Она уведомляет менеджера по персоналу о необходимости  нанять временных рабочих. (5) Закупка.  Модуль  материального  планирования  системы  R/3 оповещает менеджера по закупкам, что пришло время заказать новое сырье, а также указывает его необходимое количество. (6) Отслеживание  выполнения  заказа  и  последующие  заказы. Бразильский розничный торговец входит в систему R/З компании  ISC через Интернет и  видит,  что часть заказа была выполнена. Кроме того, он может при этом сделать следующий заказ.

Резюме В данной главе мы рассказали о производителях ERP систем и о самих системах для того, чтобы облегчить понимание материала последующих глав и дать общее представление об индустрии ERP систем.  Были  рассмотрены  партнерские отношения  между производителями ERP систем и  консультантами,  а также другими  партнерами. На примере систем SAP и Oracle были представлены сведения о модулях систем планирования ресурсов предприятия,  а также определены  понятия  моделей,  объектов и  процессов ERP систем.  И,  наконец, был рассмотрен пример использования ERP системы (SAP).

Литература ASAP [World Consultancy]  (1996). Using SAP R/З.  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,  November 3,  pp.  162-6.

42

ЧАСТЬ ВТОРАЯ. ERP СИСТЕМЫ

Freeman, E. (1997). «ERP Recipe?» Datamation, August, pp. 61-4. Greenberg, I. (1997a). «Oracle, PeopleSoft Target C/S Apps 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). «A 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, С (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.A1. 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  г. (прим.  автора).

43

ERP  СИСТЕМЫ

Мы  приняли  решение  работать с  системой  SAP.  Мы  могли  принять это решение по многим причинам, но, возможно, главная из них заключается в том,  что один из способов,  которым вы можете изменить (корпоративную — прим. ред.) культуру, состоит в том, чтобы начать  управлять  потоками  информации,  доступностью  информации, тем, кто что может знать, сколько может знать и о чем... И мы подумали:  «Как нам изменить... традиционную культуру нашего предприятия и сделать его похожим на небольшое предприятие с  меньшей  иерархией  и  большим  потоком  информации,  где  будет меньше опасений  и  больше  командной  работы?» Как это сделать?  Конечно,  ...  нет панацеи  от всех бед.  Одной  из причин в любом случае была та, что мы нуждались в замене своих систем  ... У нас действительно была устаревшая и  примитивная бухгалтерская система,  ее нужно было менять.

SAP  в  сталелитейном  производстве К  1999  г.  система  планирования  ресурсов  предприятий  SAP  R/3 была успешно  внедрена  несколькими  фирмами  сталелитейного  производства.  Для  Geneva  Steel  сигналом  было  то,  что  в  1995-1996  гг. швейцарская  фирма  Kindlimann  AG  внедрила  SAP  R/3  (версию  2.2), используя  модули финансового учета и управления (FI/CO), логистики  с  системами  продаж  и  дистрибуции  и  управления  запасами (SD/MM),  а также управления  персоналом  и  основными  средствами (HR/AM).  В то время член  правления  компании Kindlimann сказал  : Внедрение  системы  SAP  было  для  нас  стратегическим  шагом для сохранения в будущем лидирующего положения на рынке. Конкурентоспособность все больше зависит от информационных технологий, которые прямо влияют на цены, качество и взаимодействие с клиентами.  Система SAP в сочетании с энтузиазмом и приверженностью всех наших служащих — это средство оптимизации и координации этих факторов. Нью  Стил  (май  1997)  сообщает,  что  компании  LTV,  Hylsa,  Bonier, Arbed,  Sidmar,  Preussag,  Thyssen,  Krupp-Hoesch,  Mannesmann, Hoogovens, Kidlimann и ВНР приобрели ПО SAP R/3. Кроме того, ком-

*  Kindlimann  AG,  SAP  (без даты)  (прим.  автора).

44

ЧАСТЬ  ВТОРАЯ.  ERP СИСТЕМЫ

пания 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  в качестве собственно-

*  Выставления  счетов  (прим.  науч.  редактора). **  Базируется на данных, опубликованных на pecypcaxeddy.media.utah.edu и www.geneva.com,  а  также  обсуждениях  в  «Истории  компании  Geneva  Steel»  (см. www.geneva.com)  (прим.  автора).

45

ERP СИСТЕМЫ

сти Basic Manufacturing and Technology штата Юта.  К январю  1999 г. председатель  правления  компании  Geneva  Steel  (Джозеф  Кеннон) и  ее  президент  (Роберт  Гроу)  были  собственниками  половины предприятия*.  В таблице  3.1  представлены  его  операции  в  19961998 гг. Таблица 3.1. Отчеты об операциях компании Geneva Steel

Чистая сумма продаж Себестоимость реализованной продукции Валовая прибыль Затраты на реализацию, общие и административные расходы Списанные активы Операционный доход (потери) Другие доходы (расходы) Процентные и иные доходы Затраты на выплату процентов Прибыль до уплаты подоходного налога Отчисления на уплату подоходных налогов Чистая прибыль(потери)

1998

1997

1996

720,453 659,132 61,321

726,669 665,977 60,692

712,657 662,058 50,350

22,116 17,811 21,394

22,488 38,304

24,943 25,729

356 (42,483) (20,733) (1,790) (18,943)

413 (40,657) (2,040) (772) (11,608)

(16,327)

Примечание: Суммы — в тыс. долларов. Источник: Пресс-релиз компании за 16 ноября  1998 г. и  12/97 Ю-К.

Geneva Steel  имела традиционную  корпоративную  культуру сталелитейного  предприятия.  По  словам Кеннона:  «Наша  культура  была  во многом традиционной культурой сталелитейного предприятия. То есть иерархичной  культурой,  в  которой  присутствовал  страх.  Страх  перед неудачей, страх перед вышестоящими лицами организации». Компания Jacobson  & Associates,  исследовавшая  вопросы удовлетворения  нужд покупателей стали, обнаружила, что Geneva Steel имеет ряд проблем в этой области. Как заметил Кеннон: «Мы были полными мертвецами».

Производственный процесс** Для  выплавки стали Geneva Steel использует железную руду,  известняк и каменный уголь (см.  рис.  3.3).  Используя самую широкую из действующих в мире линий непрерывной разливки стали и проката,  Geneva  Steel  может  производить  стальные  листы  шириной  126 дюймов.  Специальные  финишные  стенды  позволяют  раскатывать сталь в соответствии с нуждами покупателя,  варьируя ее толщину от *  Hoover's Company Capsule (прим.  автора). По  материалам  обсуждения  компании  Geneva  Steel  {www.geneva.com)) (прим.  автора).

46

ЧАСТЬ ВТОРАЯ. ERP СИСТЕМЫ

1-LMF; 2'Литпейная машина; 3. буфер горячих слябов; 4. поточное кондиционирование слябов; 5. индукционная печь; 6. печи выравнивания температуры;  7. гидравлическое регулирование кромок и снятие окалины; 8. черновой прокат; 9. режа; 10. полосное снятие окалины; 11. непрерывный 6-интервальный раскат; 12. ламинарное поточное охлаждение; IS. смотка; 14. размотка; 15. равнение; 16. обрезка кромок; 17. резка; 18. выравнивание толстого проката; 19. выравнивание тонкого проката; 20. наложение проката.

1  до 0,07 дюйма.  Geneva Steel также обладает линией резки и выравнивания листа, используемой для создания самой широкой и толстой в мире продукции этого вида.  Производственный процесс на Geneva Steel изображен на рис. 3.3.

«Мини-заводы»* С  1970 по  1985 г.  производство стали в США уменьшилось примерно в два раза.  В то время  как многие большие компании сокращали  производство,  группа малых сталелитейных компаний удвоила выпуск  своей  продукции,  используя  электродуговые  печи  или  «мини-заводы». К  1991  г. доля «мини-заводов» в производстве стали США составила  22,7%,  в то  время  как в  1981  г.  она  равнялась  15%.  Некоторые эксперты полагают, что в 2000 г. «мини-заводы» выпустят 14 млн. т горячекатанной стали, по сравнению с 3 млн. т в 1995 г. Как отмечает SteelNet: *  По материалам  ресурса www.steelnet.org (прим.  автора).

47

ERP СИСТЕМЫ

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

Информационные  системы  управления компании  Geneva  Steel По мере своего развития конфигурация информационной системы  компании  Geneva  Steel  стала  включать  несколько  неоднородных систем,  что усложнило интеграцию и доступ к информации.  Как сказал  Кеннон: У нас есть ... мейнфрейм ... и ... примитивная бухгалтерская система ... У нас много различных типов компьютеров. Им сложно общаться друг с другом. У нас большое количество мини-компьютеров различных типов с различным программным обеспечением ... Наша система — это выход из этого ада. Используемая  ныне  информационная  система  порождает  большое  количество данных о деловых операциях,  но данные  большинства этих систем, вобщем, недоступны. Как заметил Кеннон; «Мы ... порождаем буквально  миллионы  единиц  информации.  Но  ...  они  недоступны нам и,  конечно,  не интегрированы между собой». Информационная  система  предоставляет  три  основополагающих ежедневных отчета для  поддержки  решений,  принимаемых Кенноном. Один из основных отчетов,  который я рассматриваю — зто отчет об операциях. В нем приводится список... вполне определенных вещей ... [например] ... количество полос в час. Этот отчет не такой подробный,  как  отчет  о  ежедневных  операциях  (daily  operations report, DOR) или ежедневный отчет об операциях (daily report of operations, DRO)... И эти три отчета — не единственные, которые я получаю. Я не говорю об отчетах о продажах... Они идут отдельно... У нас также есть более толстые отчеты по многим другим вопросам, поми-

48

ЧАСТЬ ВТОРАЯ. ERP СИСТЕМЫ

мо продаж: по бухгалтерии, транспортировке и [другим] операциям. Но те отчеты,  о  которых я только что упомянул,...  — ежедневные отчеты.  А  еще  у  нас  есть  отчеты,  которые  формируются,  по  крайней мере,  каждую  неделю  или,  может быть,  немного чаще  ...-  отчеты  по информации  о  продажах.  Хорошо,  что  я  получаю большую  часть отчетов  по  электронной  почте  и  фактически  не  имею дела с  большим количеством бумаг.  Но точно — это отдельные отчеты. К  сожалению,  информационная  система  предоставляет  ограниченную  информацию  о  клиентах  и  их заказах. Может быть, что-то, чего мы не знаем о расходах на горячий металл,  поступающий для конкретного  клиента.  Я думаю,  что  мы  интуитивно знаем это  и,  может быть,  в  некоторых случаях мы  это действительно знаем. Торговым  представителям  ...  трудно  вычислить,  где  находится заказ. Кроме  того,  используемая  информационная  система  ограничивает связи  с клиентами.  Как сказал  Кеннон: Как  [клиенты]  ...  получают  информацию?  Как они узнают,  когда часть стали прибывает в их распоряжение? Соответствует ли это заказу? Придет ли он тогда, когда они его заказывали? Все это — те вещи,  которые могут быть улучшены путем расширения коммуникаций с ними и коммуникаций внутри компании. В  используемой  ныне  информационной  системе  интеграция  информации  —  критически  важная часть работы  менеджеров компании. Интеграция  —  по  большей  части,  интеллектуальная.  Другими словами,... менеджеры — это интеграторы. Я рассматриваю продажи,  отчеты  о  ежедневных операциях  и  ежедневный  отчет об  операциях.  Честно  говоря,  мы  больше  используем  ежедневный  отчет  об операциях, однако у нас много и других отчетов... Но на основе ежедневных  операций  интеграция  происходит  в  голове  у  человека,  и, будем надеяться,  у человека,  работающего с другими людьми. Кроме того,  [когда]  ...  мы составляем бизнес-план,  ...  нам приходится делать усилия,  чтобы  интегрировать информацию...

49

ERP СИСТЕМЫ

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

Проект «Дельта» компании Geneva Steel В  1997  г.  Geneva Steel  начала  реинжиниринг —  проект «Дельта». Его целью было «произвести систематические и глубокие изменения с учетом корпоративных систем, процессов и структур». Задачей было снизить затраты на 20% по сравнению с 1996 календарным годом. Как сказал Кеннон в пресс-релизе в марте 1997 г.; Наши попытки снизить административные издержки являются только частью большого проекта,  названного  проектом «Дельта» и направленного на систематические изменения способа, которым мы  ведем бизнес в Geneva Steel.  В течение последних нескольких месяцев  несколько  команд начали  работать над улучшением всех аспектов деятельности нашей компании, включая услуги клиентам, взаимодействие между служащими и операции. Эти начинания  необходимы  для  того,  чтобы  оставаться  конкурентоспособными на рынке стали. Недавнее резкое повышение импорта стали  и растущее  производство  внутри страны усилили конкуренцию  на  рынке.  В ответ мы  осуществляем системные  изменения с целью обеспечения нашей долгосрочной конкурентоспособности. Проект «Дельта»  начал  порождать ряд изменений.

Организационные изменения 2  июня  1997  г.  Geneva  Steel  объявила  о  перераспределении  ответственности  в управлении  между исполнительными директорами. Согласно пресс-релизу компании:

50

ЧАСТЬ  ВТОРАЯ,  ERP СИСТЕМЫ

Изменения  в  нашей  структуре  управления  направлены  на  сосредоточение наших ресурсов в тех областях, которые могут принести  изменения  к наибольшим усовершенствованиям  в компании  ... Изменения в отношении отчетности  направлены на то,  чтобы отразить  приверженность  компании  к тому,  чтобы  стать  горизонтально направленной организацией, сфокусированной на внедрении стратегического плана. С  сентября  1997  г.  административный  и  исполнительный  штат сотрудников Geneva Steel был сокращен с 328 до 219 человек,  а операционный  менеджмент — со  155 до 92 человек*.

Организационные меры Чтобы  оценить значение  изменений  по  проекту «Дельта»,  Geneva Steel  разработала  несколько  критериев  для  обеспечения  сбалансированных измерений качества, своевременности и затрат.  Первостепенное значение  имели  следующие  показатели: •  своевременность  поставок; • аккуратность  исполнения заказов; • стоимость производства одной тонны  продукции; • административные расходы на производство одной тонны продукции; •  претензии  клиентов; •  результаты  производства  по  видам деятельности; • уровни запасов и продукции. Как сказал Кеннон: Другим  показателем  будет удовлетворенность  клиентов —  как наши клиенты смотрят на нас. Мы не делали этого так, как могли бы или должны были бы делать... Мы стремимся к интеграции с клиентами, и для этого мы проводим некоторые организационные изменения.

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

"  Geneva  Steel,  декабрь  1998  10-К (прим.  автора).

51

ERP СИСТЕМЫ

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

Результаты  внедрения  SAP,  ожидаемые  Geneva  Steel Как предвидел Джозеф Кеннон, от внедрения SAP R/3 ожидалось множество результатов.

Меньшее количество компьютерного оборудования и ПО Внедрение SAP выполняется в среде клиент-сервер. Значит, мейнфрейм компании Geneva Steel при внедрении системы использоваться не будет. Кроме того, обычно внедрение SAP везде сокращает использование традиционных приложений с 50% до 90%. И так как SAP — интегрированное приложение, то станет меньше компьютерного оборудования и ПО, а сама система SAP будет полностью интегрирована. Возможности  отчетности Кеннон ожидал, что SAP обеспечит более надежные и интегрированные возможности отчетности:  «Одним из достоинств SAP является то, что она совмещает все отчеты [о продажах, о ежедневных операциях (DOR)  и  ежедневный  отчет об операциях (DRO)]  ...  и  вам  нет необходимости  иметь три  отдельных отчета». Доступность  информации Кеннон  отметил,  что  с  внедрением  SAP должен  улучшиться доступ к информации: Мои ожидания от SAP состоят в том, что вы получаете интегрированный  инструмент...,  который сам по себе  ничего не будет делать, но позволяет иметь больший доступ к информации в более понятной, действенной форме, в форме более удобной для использования. Кеннон также считал,  что SAP сделает информацию (например, о продажах) более доступной и внутри компании, и, в конечном счете, для клиентов: «Если у вас есть номер партии и система,  которая ... позволяет связываться с ней, то люди в различных частях организации  могут иметь больше информации о том,  что их интересует».

52

ЧАСТЬ  ВТОРАЯ.  ERP  СИСТЕМЫ

Пользователи информации Кеннон  надеялся,  что  SAP  обеспечит  более  стратегическое  использование  информации,  способствуя  задаванию  вопросов  типа «что если?»,  и таким образом улучшит процесс принятия решений. Надеюсь,  что  [наше  использование  информации  будет]  более стратегическим... Я думаю, что это дает в руки [менеджмента] инструмент/оружие для того,  чтобы  привести  нас  в  состояние более ранней  готовности:... «Вы думали об этом?». Я  думаю,  это  даст  нам  большую  возможность  задавать  вопросы  «что,  если  попробовать  это?»  или  «что,  если  попробовать то?»  Я  думаю,  у  нас  будет  база  данных  и,  задав  вопрос  «что произошло,  когда  мы  сделали  это?»,  мы  сможем  обратиться  к ней  и  получить  ответ. Кроме того, Кеннон считал, что возрастет доступ к данным и, как результат,  —  возможность  анализировать  взаимосвязи  между  группами  данных: Данных будет  все  больше  и  больше  ...  Можно будет соотнести две переменные. Вы сможете более точно и прямо соотнести продажу определенного продукта со всеми издержками. Наконец,  Кеннон  считал,  что  SAP  обеспечит  большие  возможности  —  такие  как  возможность  постановки  вопросов,  —  о которых  можно  будет  узнать  и  которые  понять  можно  будет  до конца  только  после  внедрения  системы:  «Она  предоставит  вам большее  пространство  для  игры,  чтобы  узнать  о  многих  вопросах,  о  некоторых  из  которых  я  еще  не  знаю,  но  которые  со  временем  возникнут».

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

S3

ERP СИСТЕМЫ

Организационные взаимодействия в бухгалтерских и информационных системах Кеннон предполагал, что внедрение SAP приведет к более тесному взаимодействию бухгалтерских и  информационных систем  и  интеграции бухгалтерской деятельности с деятельностью команды менеджеров. [Я ожидаю], что наши специалисты в области бухгалтерии, наш главный  финансовый  администратор  и  управляющий,  входящие  в эту команду,  [будут работать] как единое целое с командой менеджеров... Я ожидаю действительно тесной интеграции бухгалтерских и информационных систем. И что это приведет к созданию структуры для принятия решений. Кроме  того,  предполагается,  что  внедрение  SAP  повлияет  на число бухгалтеров и персонала, сопровождающего информационные системы. Как заметил Кеннон: В первую очередь, у нас будет меньше бухгалтеров и,  возможно, меньше администраторов информационных систем. Потому что одна из вещей, которые мы рассматриваем, это сокращение части этих функций. Когда будет внедрена система SAP, большую часть того, что делают бухгалтеры ... не нужно будет делать. Как  результат,  компания  Geneva  Steel  предполагала  сократить свой  штат  сотрудников  подразделения  информационных  технологий  примерно с  80 до  12  человек,  а  штат  бухгалтерии  —  с  60 до 10 человек.

Планирование и информация Кеннон  также  считал,  что  система  повлияет  на  удовлетворенность клиентов и на способность компании планировать: «Другая область влияния системы [SAP] — это то, как мы планируем... Системе производственного процесса очень важно то, как вы планируете снижение выпуска продукции. Это [только] один ее аспект».

Ввод  в  эксплуатацию  системы  SAP  в  Geneva  Steel В декабре  1997 г. Geneva Steel объявила о том,  что она начинает внедрение системы  SAP  R/3.

54

ЧАСТЬ ВТОРАЯ, ERP СИСТЕМЫ

Компания  выбрала  и  начала  внедрение  ПО  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.  «Это слишком дорого»,  «Это  слишком трудно»,  «Просто  покупается  новая

55

ERP  СИСТЕМЫ

игрушка»...  Я  слышал  подобное и  много чего другого от противников  внедрения  SAP..  Даже  сегодня  я  не думаю,  что ситуация  полностью  изменилась...  Я  думаю,  мы  получили  критическую  массу  людей,  которые поддерживают нас.  И когда  смотришь на  проводимое здесь обучение,  видишь намного больше веры  в SAP.  И,  собственно говоря,  люди,  наконец,  поняли,  что,  нравится  им  это  или  нет,  это должно произойти.

Вопросы 1. Какие проблемы были у Geneva Steel с традиционной системой? 2.  Каковы результаты внедрения SAP,  ожидаемые Geneva Steel? 3.  Может ли SAP оправдать эти ожидания? 4. Что вы думаете по поводу показателей, которые Geneva Steel планировала использовать для  оценки  проекта  «Дельта»? 5.  Geneva Steel  планирует использовать SAP для изменения своей  корпоративной культуры. Каковы достоинства и недостатки такого подхода к изменению корпоративной культуры?

4 ВВОД  ДАННЫХ  В  ERP  СИСТЕМАХ

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

56

ЧАСТЬ  ВТОРАЯ.  ERP СИСТЕМЫ

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

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

57

ERP  СИСТЕМЫ

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

Источники выгод и затрат при вводе данных: последствия реинжиниринга Системы  планирования  ресурсов  предприятий  способствуют многим  принципам  реинжиниринга,  перечисленным  Хеммером (Hammer 1990) и другими исследователями. Некоторые из этих принципов в конечном  итоге влияют на ввод данных. Хотя  реинжиниринг может улучшить организационные процессы,  источники выгод могут вызвать недовольство  пользователей.  Эти  источники  изменений отражены в таблице 4.1.

Однократный сбор данных Существует  большое  число  преимуществ  однократного  сбора данных  по  сравнению  с  многократным.  Если  данные  собираются только один  раз,  расходы обычно меньше.  Если данные собираются только  один  раз,  то  все  пользователи  находятся  как  бы  на  «одной странице» используемых данных, так что прогнозы и т. п. будут сделаны с  использованием тех же данных.  Расходы  на обновление данных при этом ниже, так как нужно будет обновить только один экземпляр данных. Системы планирования ресурсов предприятий обычно используют структуру реляционных БД,  поэтому если одна часть информации была собрана, снова собирать ее не нужно. Однократный сбор данных гарантирует, что пользователи имеют доступ к одним и тем же данным в одно и то же время, что одни и те же данные используются всей фирмой для планирования и управления. Кроме того, так как данные собираются только один раз, фирмы рассматривают ERP системы как системы,  предоставляющие  возможность  сократить  число  конторских служащих  и  соответствующие  расходы.  Конторские  служащие  и  те,

58

ЧАСТЬ ВТОРАЯ. ERP СИСТЕМЫ

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

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

Ввод данных непосредственно в компьютер Изменяются  не только количество данных и то,  сколько раз они собираются, но и средства их сбора. Как сказал менеджер проекта по внедрению SAP R/3 компании Purina Mills: «Мы берем людей, которые записывали часть информации на бумаге, и сажаем их за персональные компьютеры» (Stedman  1998b). Преимущества такого подхода могут быть очень большими, так как больше не существует промежуточного дублирования данных (с бума-

59

ERP  СИСТЕМЫ

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

Сбор данных на месте их создания При  использовании  традиционных  систем  необходимы  различные  служащие,  которые  собирают  данные  для  ввода  их  в  систему. Информация  на  бумаге  доставляется  бухгалтерам,  которые,  в  конечном  счете,  несут ответственность за ввод данных  в систему.  При использовании ERP системы сбор данных происходит ближе к месту их  создания.  Как  сказал  руководитель  проекта  по  внедрению  ERP системы  компании  Purina  Mills:  «У  нас  больше,  чем  когда-либо,  людей,  вводящих информацию»  (Stedman  1998b).  В результате,  персонал, занимающийся сбором данных, — не бухгалтеры, а люди, занимающиеся  выполнением  операций.  В  некоторых  компаниях  ожидается,  что  это  изменение  приведет  к  сокращению  числа бухгалтеров и  клерков,  как в случае с компанией  Geneva Steel,  рассмотренном  в третьей  главе. Улучшат ли эти изменения  качество ввода данных, определит конкуренция. С одной стороны, данные могут стать более точными,  потому что, в отличие от традиционных систем,  им не нужно проходить через различные уровни организации перед их вводом в систему. Например,  при использовании многих традиционных систем данные фиксируются  на бумаге  на  погрузочной  площадке,  обрабатываются  бухгалтерами и затем  вводятся  в систему.  При использовании ERP системы данные  обычно  собираются  на  погрузочной  площадке  и  непосредственно передаются в Главную книгу и в финансовые отчеты. С другой  стороны,  бухгалтеры  выбрали  работу,  которая  связана со  сбором  данных  и  передачей  информации.  А  производственный персонал  (например,  работники  погрузочной  площадки)  во  многих случаях не будет заинтересован  во  вводе данных в  ERP систему и  не сможет их вводить.  В результате персонал, вводящий данные, может повлиять на их качество или  может нуждаться  в дополнительном обучении. Следовательно,  изменения,  приводящие к сбору информации прямо  у  ее  источника,  не  будут  иметь  низкую  стоимость  с  учетом множества работников. Таким  образом,  для  уменьшения  недовольства  пользователей, возможно,  потребуются  изменения  в  системе.  Например,  как  за-

60

ЧАСТЬ ВТОРАЯ.  ERP СИСТЕМЫ

метил  руководитель  отдела  управления  информацией  компании Hydro  Agri:  «Пользовательский  интерфейс  SAP  был  сложным  для работников погрузочной площадки, которые вводят данные о количестве  ввозимых  и  вывозимых  химических  препаратов»  (Stedman 1998b).  В  результате,  компании  Hydro  Agri  пришлось  создать  интерфейс  для  улучшения  практичности  и  доступности.  Такие  проблемы  могут замедлить процесс внедрения  и  вызвать недовольство пользователей.

Сбор данных с акцентом на процессе (а не на функции) В  традиционных  системах  сбор  данных  обычно  базируется  на нуждах  конкретных  функциональных  приложений.  В  ERP  системах, базирующихся  на  событиях,  сбор  данных  осуществляется  с  точки зрения кросс-функциональности, т. е. с акцентом на процессе. В результате,  если информация собирается у источника ее порождения, то  последовательность  происхождения  данных  может  изменяться вместе с процессом. Кроме  того,  при  использовании  традиционных  систем  скрытая модель фирмы, вероятно, более основана на функциях,  которые фокусируются  на  конкретных  функциональных  информационных  нуждах.  Переход  к  межфункциональным  событиям  может  породить  модель фирмы с более широкой основой, удовлетворяющей более широкому  диапазону  информационных  нужд.  Системы  планирования ресурсов предприятий, такие как SAP,  моделируют фирму на уровне определенных  «пусковых  механизмов»  —  различных  событий,  определяющих,  когда нужно собирать информацию для системы. В книге Ванга, Гилланда и Ли (Whang, Gilland, and Lee 1995, с. 8, 26) говорится о том, что среди пусковых механизмов SAP могут быть следующие: •  сбытовая деятельность,  начиная с контакта с клиентом; •  прием грузов, начиная с заказа на поставку; •  резервирование  материала  для  запланированного  использования; •  проблемы с товарами (например, изъятие материала); • отправка по  почте  (изменение  номера партии,  изменение названия среди подразделений); •  перевод  акций  (например,  перемещение  внутри  компании  с одного предприятия на другое); •  перемещение товаров по наряд-заказам (детали со склада, готовые товары на склад). В некоторых случаях некоторые акценты по сравнению с тем, как традиционная  система  собирает  ту  же  самую  информацию,  могут

61

ERP  СИСТЕМЫ

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

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

Рис.  4.1  Изменение  процесса  и  персонала,  собирающего  данные

62

ЧАСТЬ ВТОРАЯ.  ERP СИСТЕМЫ

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

Слишком много окон и слишком много времени на  ввод данных? Системы  планирования  ресурсов  предприятий  —  это  готовое ПО,  разработанное для внедрения различными фирмами. Для обеспечения гибкости системы и охвата более широкой информационной базы окна для  ввода данных ERP системы основаны на предоставлении  наиболее общих возможностей  проектирования.  Не удивительно, что многим фирмам не нужны все возможности сбора данных, которые  предоставляются  этими  большими  ERP  системами.  Однако конфигурирование не может уменьшить число окон, которые должны быть заполнены.  Например,  версии  системы  SAP  R/3,  предшествовавшие версии 4.0, были менее гибкими в перенесении полей данных в единое  окно.  В  результате,  ввод данных в  ERP  системе  может  потребовать  большего  количества  окон,  чем  если  бы  последовательность  окон  была  бы  специально  разработана  для  конкретных  нужд ввода  данных.  Большее  число  окон  означает  большее  количество данных,  больше  времени  и,  следовательно,  больше  персонала  для ввода данных.  Системам,  специально  разработанным для  нужд конкретной  компании,  может,  таким  образом,  потребоваться  меньшее время на ввод данных и меньше ресурсов, чем ERP системе.

Hydro Agri В канадских магазинах фирмы Hydro Agri обработка заказа фермера занимала раньше 20 секунд.  Однако  после установки  системы SAP R/3 время обработки возросло примерно до 90 секунд (Stedman 1998b). Так как Hydro Agri имеет около 30 000 заказов каждые четыре недели, новой системе для ввода данных требовались огромные ресурсы. До установки R/3 для обработки заказов каждые четыре неде-

63

ERP  СИСТЕМЫ

ли требовалось 600 000 секунд,  после установки — 2 700 000 секунд. В  результате,  заказы  пришлось  принимать  штату  сотрудников  подразделения  информационных  технологий. Используя  R/3,  работникам  пришлось  вводить  данные  в  шесть окон. В предыдущей же (собственного производства) системе для ввода данных было только одно окно. Кроме того, рабочие процессы в системе R/3 значительно отличались, так что даже работники, ответственные за ввод данных, были другими по сравнению с системой собственного производства. Следовательно,  переход к новой системе привел к появлению необходимости дополнительного обучения  персонала. По  словам  руководителя  управления  информацией  фирмы  Hydro Agri,  увеличившиеся  требования  к  вводу  заказов  «грозили  стать  концом  всего».  Таким  образом,  фирма Hydro Agri  была вынуждена выбирать между установкой какого-то нового пакета для ввода заказов или разработкой  своего  собственного  пакета,  сделанного  на  заказ. В конечном итоге Hydro Agri решила эту проблему, создав приложение между R/3 и пользователями для упрощения  и объединения доступа.

Почему увеличилось количество окон для ввода информации и время обработки данных? Перенесение внимания  с функции на процесс привело к изменению последовательности сбора информации, а также того, кто должен собирать  информацию,  и,  как  результат,  —  к  различному  числу  окон для  ввода данных.  Например,  в  фирме  Hydro Agri  в системе  R/3 было шесть окон, в то время как у традиционной системы — всего одно. ERP система была создана, исходя из процесса, с учетом множества источников информации — отсюда необходимость нескольких окон. Однако традиционная  система была создана для  удовлетворения  конкретной функциональной потребности.  В результате в данном случае, возможно,  не было хорошего соответствия  ПО существующему организационному процессу. Позже в данной книге мы более подробно рассмотрим отношения между организационными процессами и ПО.

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

64

ЧАСТЬ  ВТОРАЯ.  ERP СИСТЕМЫ

Рис.  4.2  Число  окон  для  ввода  данных  и  операций немного, любое увеличение ресурсов,  происходящее из-за увеличения работы по вводу данных,  в общем,  не будет иметь серьезных последствий.  Однако если  количество операций  велико,  то значительное увеличение числа окон (по сравнению с традиционной системой) приведет  к  значительному  увеличению  ресурсов,  необходимых  для ввода данных. В результате, если разница большая (например, в компании Hydro Agri соотношение было 6:1), и существует большое количество  операций  (30  000  в  компании  Hydro  Agri),  то  систему  будет труднее внедрить, если не уменьшить число окон (как это было сделано в Hydro Agri). Такое усложнение внедрения изображено на рис. 4.2. Соотношение числа окон для ввода данных в ERP системах и числа окон для ввода данных в традиционной системе также может быть мерой оценки соответствия ERP системы существующим организационным процессам. Большой разрыв показывает, что организационные процессы и процессы ПО в значительной степени отличаются, и возможно индицирует несоответствие ПО существующим процессам.

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

65

ERP СИСТЕМЫ

Недостаточное внимание пользовательскому интерфейсу Некоторые специалисты утверждают, что разработчики ERP систем  не  уделили  достаточного  внимания  пользовательскому  интерфейсу.  Как сказал президент Human Factors International: Разработчики данных  [ERP]  пакетов все без исключения  исходят из подхода с точки зрения системы, а не с точки зрения пользователя  ...  [Из-за системы  производительность пользователей  снижается, так как она заставляет их «метаться между окнами» — работать то с клавиатурой, то с мышью.] ... Это программное обеспечение просто выводит людей из себя. (Stedman 1998b). Другие специалисты,  например,  аналитик из AMR  Research,  утверждают, что проблемы с вводом данных в ERP системах возникают из-за того, что их разработчики в основном «проектировали, исходя из базы данных,  а не из  пользовательского интерфейса.  Окна  были последним, о чем они думали».

Процессы и ввод данных В  некоторых  случаях  снижение  производительности  при  вводе данных не так важно, как наличие информации для принятия решений и изменения других процессов. Как заметил директор по коммуникациям  компании  Procter  &  Gamble:  «Более  высокая  производительность при вводе данных и  получении сырья — не главная  цель ...  Реальные преимущества получают те,  кто планирует бизнес,  менеджеры по материалам и другие пользователи низших звеньев. Ввод данных требует в настоящее время больших усилий»  (Stedman  1998b).

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

* Имеется в виду представление информации на экране компьютера (прим. науч. редактора).

66

ЧАСТЬ  ВТОРАЯ.  ERP СИСТЕМЫ

Некоторые ERP системы проще в использовании, чем другие Некоторые системы могут быть проще в использовании, чем другие,  но  простота использования — это не единственная  переменная, которая влияет на выбор системы. Например, компания SunAmerica в конечном итоге выбрала SAP, хотя, как сказал вице-президент расчетного отдела на ежегодном собрании  компании SunAmerica:  «Система PeopleSoft очень привлекательна,  когда смотришь на окна,  в то время как [R/3]  была внешне непривлекательной»  (Stedman  1998a). Однако  другие  пользователи  обнаружили,  что  система PeopleSoft  не  проста  в  использовании.  Как  заметил  Стедман (Stedman  1998b,  с.  24),  компания Algoma Steel  начала использовать пакет управления  персоналом системы  PeopleSoft,  но работники для получения  информации все еще обращаются  к мейнфрейму.  Одна из причин  в том,  что «работникам  приходится бороться с  многочисленными окнами системы PeopleSoft, в то время как старая система имеет только два или три  окна». Некоторые  пользователи утверждают,  что конкретными  ERP системами нужно уметь пользоваться.  Например,  главный управляющий по информации (Cief Information Officier, СЮ) компании A-dec (производящей  стоматологическое  оборудование)  обнаружил,  что  после того,  как  компания  A-dec  установила  ERP  систему  компании  BAAN (Stedman 1998b, с. 24), •  число  звонков  в  справочную  компании  увеличилось  на  65% (СЮ сказал: «Это прямо говорит о том, что нужно уметь пользоваться  этим  приложением»); •  система не уменьшала запасы  на то  количество,  которое было отправлено.  Хотя  работники  складов  ввели  необходимые данные о  вывозе запасов,  им  пришлось в другом  окне  подтверждать операцию,  прежде чем система производила вычет из запасов.  К сожалению, система не потребовала подтверждения.

Разработчики пытаются сделать системы более простыми для использования Простота  использования  — достаточно  важный  фактор.  Как сказал  Басе  (Busse1998),  SAP  пытается  сделать  систему доступной  для большего числа пользователей.  Как заметил Хассо Плеттнер,  главный администратор  (Chief  Executive  Officer,  CEO)  и  один  из  основателей компании SAP:  «Я хочу,  чтобы люди могли использовать часть [системы  R/3] без дополнительного обучения».  В результате,  компания SAP начала то, что она называет «EnjoySAP»,  в качестве попытки сделать

67

ERP  СИСТЕМЫ

R/3  проще в использовании  и легко приспосабливаемой  к более широкому  кругу  условий  работы.  Эти  попытки  задействуют  различные технологии,  включая сенсорные экраны для упрощения ввода данных. Однако  Стедман  (Stedman  1998a),  цитируя  Плеттнера,  говорит: «В результате не такое количество пользователей используют SAP,  какое мы ожидали». Этот вопрос важен для производителей ERP систем по  нескольким  причинам.  Во-первых,  если  система  недостаточно проста  в  использовании,  ее  могут  не  продать  стольким  фирмам, скольким  могли  бы,  будь  она  проще.  Во-вторых,  если  простота  использования  не  будет  иметь  значения  при  внедрении  системы  конкретными фирмами, она все равно может повлиять на доходы, потому что  доходы  часто  зависят  от  количества  проданных  «рабочих  мест» (т.е.  от числа пользователей системы).  В результате,  некоторые фирмы  предоставили  менее  заинтересованным  пользователям  доступ  к финансовой и другой информации через intranet, оставляя прямой доступ к сети только экспертам (Bashein, Markus и Finley 1997). Важно отметить,  что «простота использования»  в некоторой  степени  «находится  в  глазу  наблюдателя».  Если  система  кажется  нам знакомой, нам, возможно, проще ее использовать. Например, Браунли  (Brownlee  1996)  говорит,  что  один  пользователь  заметил:  «Я  не знал, как работает старая система... Я думаю, что, возможно, в этом мое  преимущество».

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

68

ЧАСТЬ  ВТОРАЯ.  ERP СИСТЕМЫ

Хотя  все  производители  ERP  систем  признают  важность  потенциала ввода данных,  некоторые системы  окажутся,  возможно, более простыми  в использовании,  чем другие.  В любом случае,  разработчики  ERP систем делают попытки  (например,  «EnjoySAP») сделать системы более простыми в пользовании.

Литература 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, pp. R12, R17. Busse,  T.  (1998).  «SAP  to  Broaden  Access  to  R/3».  Computerworld, September  15. Hammer,  M.  (1990).  «Reengineering Work:  Don't Automate,  Obliterate».  Harvard Business  Review,  July/August,  pp.  104-12. Koch, С (1999). «The Most Important Team in History». CIO Magazine, October 15. Stedman,  С  (1998a).  «R/3  Complexity  Stymies  Users».  Computerworld  , September  21. Stedman,  С  (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.

5 ВОЗМОЖНОСТИ  ВЫВОДА ДАННЫХ В  ERP  СИСТЕМАХ

Доступ к информации в ERP системах сначала ограничивался отчетами,  которые  можно было  получить из  системы  или  через запросы к БД, лежащей в основе модели БД. Однако в последнее время организации  стали  использовать  для  дальнейшего  распределения  информации,  созданной  ERP  системой,  intranet  и  хранилища  данных. Кроме того,  чтобы предоставить пользователям  индивидуальный доступ  к  различной  информации,  производители  ERP  систем  начали разрабатывать  «порталы».  Это  привело  к  упрощению  использования и,  следовательно,  к появлению  новых возможностей для  производителей  ERP систем в электронной коммерции.

69

ERP  СИСТЕМЫ

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

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

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

70

ЧАСТЬ ВТОРАЯ.  ERP СИСТЕМЫ

Системы  планирования  ресурсов  предприятий  были  спроектированы для обработки операций.  Поэтому, не удивительно, что в некоторых ERP системах запросы рассматриваются как операции. Однако,  чем  больше  сделано  запросов,  тем  больше  опасность  перегрузки системы; слишком большое число запросов может увеличить время ответа и неблагоприятно отразиться на пользователях. Например, как заметил Коч (Koch 1999): Отчеты  являются большой проблемой  ERP систем,  потому что впервые сотни, даже тысячи служащих обращаются к единственной интегрированной базе данных ERP системы и выводят огромное количество данных ... Это проблема технологии номер один, которую команды по внедрению ERP системы должны устранить после внедрения системы. Таким образом, важной частью планирования производительности  ERP системы  является определение того,  как будет определен и осуществлен вывод данных.  Если он осуществляется через запросы, то потребуются дополнительные оборудование и пропускная способность сети.

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

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

71

ERP  СИСТЕМЫ

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

Intranet Так как ERP системы, в общем, не просты в пользовании, некоторые фирмы  помещают отчеты  в  Интернет или в intranet.  В частности, для  различных уровней  пользователей  могут быть созданы  различные среды  создания  отчетов.  Например,  пользователям-экспертам  можно предоставить прямой доступ к SAP, в то время как остальным — доступ к той информации, которая им нужна, в удобном для использования формате в корпоративной сети intranet. Интеграция intranet и ERP системы все в большей степени становится  средством  распространения  отчетной  информации  в  ERP системах. Например, компания Transamerica в Лос-Анджелесе использует  intranet для  того,  чтобы  сделать доступной  отчетную  информацию из системы  PeopIeSoft.  Отчеты,  разработанные для того,  чтобы удовлетворить  и  общий,  и  конкретный  интерес  при  принятии  решений, обновляются  каждые  24 часа. Более того, для доступа к данным ERP системы, чтобы генерировать более удобные для  чтения  и  использования  отчеты,  может быть использован и Lotus Notes . Например, Lotus Notes дает доступ к данным систем PeopIeSoft и SAP (Doan 1996). Такой доступ позволяет организациям делать данные ERP систем доступными в системе, знакомой  пользователям,  к которой легко получить доступ и которую просто  использовать. Отчеты,  опубликованные  в  intranet,  обычно  являются  стандартными  отчетами,  распространяемыми  для  общего  доступа.  В  результате,  сама информация  в  целом  почти та же самая,  что  и  находится  в  отчетах  ERP  системы.  Что  меняется,  так  это  доступность: информация  становится  доступной  для  более  широкого  круга пользователей.

* Lotus Notes — система поддержки групповой  работы компании  IBM/Lotus (прим.  науч.  редактора).

72

ЧАСТЬ  ВТОРАЯ.  ERP СИСТЕМЫ

Хранилища данных В  некоторых случаях ERP системы  имеют  интерфейс  к хранилищам данных. Хранилища данных могут предоставить, по крайней мере,  две  возможности.  Во-первых,  они  дают  пользователю  возможность получить доступ к информации, необходимой для принятия решений,  в среде,  созданной  для  генерирования  отчетов.  Во-вторых, хранилище  данных  может  функционировать  как  класс  «клиринговых домов»  по отношению к приложениям, обеспечивающим исходящие и  входящие  потоки  данных  как  для  внутренних,  так  и  для  внешних пользователей.  Например  (Cotteleer,  Austin,  and  Nolan  1998,  с.  10), компания  Cisco  использовала  хранилище  данных  при  внедрении Oracle Applications: Так как последствия внедрения [Oracle Applications] для исходящих потоков были  большими,  чем  ожидалось,  команда  внедрения решила обратиться  к некоторым другим техническим  источникам. Поскольку до этого системы были связаны друг с другом напрямую (т. е. по принципу «точка-точка»), при новом подходе все данные будут передаваться через «хранилище данных». Хранилища  данных  могут  быть  физически  расположены  в  одном  месте  или же  представлять из  себя  «виртуальные» хранилища, части  БД  которых  расположены  в  нескольких  местах.  В  приложении 5-1  говорится о том, как ERP система компании Quantum взаимодействует с  виртуальным  хранилищем  данных.  Далее  говорится о том,  как  компания  Burton  Snowboards  использовала единое хранилище  данных.

Хранилище данных компании Burton Snowboards (Кет pster 1998) Компания Burton Snowboards использует систему SAP R/3 как систему  обработки  операций  для  фиксации  данных,  поступающих  из трех ее офисов, расположенных в Австрии, Японии и Вермонте. Компания  обнаружила,  что  создавать  нестандартные  отчеты  в  системе SAP было слишком сложной задачей. Небольшая группа информационных  систем  не  могла  размещать  запросы  из-за  сложности  SAP.

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

73

ERP СИСТЕМЫ

Кроме того, компания обнаружила, что, используя возможности создания  отчетов  системы  SAP,  было  сложно  выполнить даже  некоторые простые задания. Например, директор подразделения информационных систем компании Burton Snowboards сказал: Нам нужно было что-то, что дало бы менеджеру службы материально-технического  снабжения  или  менеджеру  по  продукции  возможность следить за материально-техническим снабжением, не запрашивая информацию в отделе информационных систем... Эта информация  нужна  широкому  кругу лиц,  таким  как члены  наших  команд продаж,  материально-технического снабжения, управления и нашей группы информационных систем. Чтобы  удовлетворить  стандартные  и  нестандартные  запросы, компания  Burton  внедрила хранилище данных.  Она ежедневно переносит информацию из системы SAP в хранилище данных и затем использует  инструмент управления  отчетами  (Vista/EA)  для  просмотра данных.  Около 70%  менеджеров  среднего звена  компании  Burton  и почти все исполнители пользуются выходными данными системы.

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

Преимущества хранилищ данных Производители ERP систем все чаще интегрируют возможности хранилищ данных в свои системы. Из-за своей специализации на БД компания  Oracle  была,  возможно,  первым  основным  производителем, кто интегрировал хранилища данных в свой продукт. Однако SAP также вскоре выпустила продукт с хранилищем данных. Хранилища  данных  предлагают  информацию,  оптимизированную для поиска. Таким образом, так как процессы принятия решений нуждаются  в  изменениях,  хранилище  данных  может  быть  использовано для  предоставления  новых отчетов в  режиме  реального времени.  Как видно из примера компании Cisco, хранилища данных могут

74

ЧАСТЬ  ВТОРАЯ.  ERP  СИСТЕМЫ

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

Порталы  ERP  систем Так как фирмы все больше используют intranet и хранилища данных,  производители ERP систем стали предоставлять порталы, способствующие развитию доступа для  пользователей  ERP систем.  Некоторые  из  порталов  производителей  ERP  систем  представлены  в таблице  5.1. Таблица 5.1  Порталы  производителей  ERP систем Производитель J.D. Edwards Lawsort PeopleSoft SAP

Портал MyActivEra Insight II Seaport MyWorld MySAP

Среди  производителей  ERP  систем  понятие  «портал»  устоялось пока не полностью. Как сказал аналитик МЕТА group: «Эти производители собирают все, что подойдет, и смотрят, что приживется» (Holt and Lamonica 1999). В основном, портал ERP системы — это web-сайт  (в intranet или в Интернете), который предоставляет доступ к новостям и информации,  опосредованно  или  прямо  связанной  с  ERP системой. Порталы  ERP  систем  обеспечивают  поддержку  продаж  продуктов, связанных с  ERP,  в среде электронной  коммерции.  Порталы  некоторых  производителей  ERP  систем  (например,  MySAP.com  компании SAP)  позволяют предлагать свои товары или услуги другим  производителям продуктов, связанных с системой SAP. Используются две версии: для настольного компьютера и базирующаяся на web-сервере.  Компания  Lawson  выпустила недавно образцовую модель для настольного компьютера (см. рис. 5.1), разработанную  для  конкретного  работника  или  профессиональной  деятельности.  В рамках модели пользователь получает доступ к различ* World-Wide Web  —  «всемирная  паутина».  Одно  из  названий  Интернета.  Часто  так  называют  и  серверы,  на  которых  хранятся  документы,  связанные  между собой  гиперссылками  (прим.  науч.  редактора).

75

ERP  СИСТЕМЫ

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

Рис.  5.2

76

ЧАСТЬ  ВТОРАЯ.  ERP СИСТЕМЫ

Рис.  5.3 чем  столе  есть  место  для  размещения  ежедневных  новостей,  которое  может  быть  использовано  компанией  для  донесения  необходимой  информации до ее служащих. MySAP — это портал, основанный на web-сервере (см. рис. 5.2 и  5.3)  с  возможностями  персонализации.  Пользователи  выбирают нужные  им  разделы  (topics)  (бизнес-справочник,  бизнес-процессы,  тенденции  в  отрасли  и  т.  д.)  и  направления  (channels)  (например,  такие отраслевые аспекты,  как высокие технологии). Использование  intranet  и хранилищ данных означали  потерю  контроля  над  некоторой  информацией  ERP  систем,  а  использование  настольных версий портала и персонализированных станиц web-сервера возвращают контроль производителям ERP систем. В то время, как перевод информации в общую корпоративную сеть вывел ее за пределы ERP  системы,  порталы  могут  централизовать  информацию  в  среде продуктов производителя и сделать ее еще более общедоступной.

Резюме Создавать  отчеты  в  ERP  системе  можно,  используя  несколько способов, в том числе используя запросы к БД и возможности ERP систем  в  создании  отчетов.  Однако  некоторые  фирмы  сделали  информацию  доступной  для  менее  заинтересованных  пользователей  через корпоративные сети (intranet). Кроме того, важным средством создания  отчетов  или  сбора  представлений  являются  хранилища  данных.

77

ERP  СИСТЕМЫ

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

Литература Cotteleer, M., 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».  InfoWorld,  May, 31. Kempster,  L.  (1998).  «ERP,  Warehouse  Used  in  Concert».  Computerworld, September  21. Koch, С (1999). «The Most Important Team in History». CIO Magazine, October 15.

Приложение  5-1* Виртуальное хранилище данных компании Quantum Quantum Корпорация  Quantum  была  основана  в  1980  г.  Производитель различных  запоминающих  устройств  большой  емкости  компания Quantum  выпускает  накопители  на  жестких  дисках  для  персональных  компьютеров  и  все  виды  ленточных  накопителей. *  Данное  приложение  основано  на  информации,  полученной  из  следующих источников:  «Quantum  Corporation  Creates  a  «Virtual  Data  Warehouse»  to  Win  1998 Best Practices Award from the Data Warehousing  Institute,»  (www.quantum.com/corporate/pr/dataware.html);  «Category:  Architecture  Implementation  —  Meta  Data Management,  Winner:  Quantum  Corporation,»  (www.dw-institute.com);  «Brio Technology  and  Integral  Results  Work  Together  to  Ensure  Quantum's  Success,» (www.brio.com/customers/ss.quan.html);  and  «Oracle  Enhances  Discoverer  3.0 Analysis  of  Oracle  Applications  Data,»  (www.noetrix.com/o/newsroom/pr_disc2k.htm) (прим.  автора).

78

ЧАСТЬ ВТОРАЯ. ERP СИСТЕМЫ

Quantum  —  лидер  рынка  производства  и  стационарных,  и  переносных  запоминающих  устройств.  Quantum  продает  свою  продукцию  изготовителям  комплектного  оборудования  и  дилерам  во всем  мире.  Компания  имеет  девять  предприятий,  расположенных на  территории  Северной  Америки,  Европы  и  стран  тихоокеанского  бассейна.  В  период  с  1996  по  1998  гг.  объем  продаж  компании  за  финансовый  год,  завершающийся  в  марте,  возрос  с  4,4 до  5,8  млрд.  долларов.

Внедрение  ERP системы  компании Oracle В  1996  г.  Quantum  внедрила  Oracle  Applications  в  финансовой сфере и производстве, базирующуюся на СУБД компании Oracle.  В полученной  в результате системе использовалось более 40 000 основных  таблиц.  К  сожалению,  из-за  этого  огромного  количества таблиц  информацию  для  принятия  решений  использовать  было сложно.  Среда  серверной  СУБД  по  обработке  деловых  операций была слишком сложной для многих пользователей и, казалось, система обречена на то, чтобы стать хранилищем мало использующейся информации об этих операциях.  Компания Quantum должна была предпринять действия,  направленные  на облегчение доступа  к информации.

Виртуальное  хранилище  данных Чтобы  сделать  информацию  о  деловых  операциях доступной  для менеджеров  и  других  служащих,  принимающих  решения,  компания Quantum  выбрала  хранилище  данных.  Для  упрощения  доступа  к данным были созданы около 4 тыс.  упрощенных и бизнес-ориентированных  представлений  БД.  Кевин  Конвей,  менеджер  по  программам подразделения  информационных систем,  рассказал: Цель нашего подразделения — обеспечить конечным пользователям доступ  к корпоративным данным для  ведения бизнеса. Нам  нужно  было  сделать доступными для  конечных пользователей  все данные о деловых операциях в качестве рабочей бизнес-информации  в  системе  планирования  ресурсов  предприятия  фирмы Oracle  и  сделать его  всеобъемлющим,  имея  большое число  различных бизнес-единиц.

79

ERP СИСТЕМЫ

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

Использование  хранилища  данных В  настоящее  время  хранилище  данных  обслуживает  в  среднем 250 пользователей (в любую смену) 23 часа в сутки, шесть дней в неделю. Им пользуются служащие предприятий корпорации, расположенных по всему миру. Система была спроектирована для удовлетворения потребностей в информации служащих, занятых в различных видах деятельности компании Quantum, включая перевозки, финансы, продажи и управление, а также операционных и временных менеджеров. Диана  Шен,  менеджер  по  управлению  стратегическим  процессом,  заметила: Эта  система  предоставляет  нам  доступ  в  режиме  реального времени к данным в виде консолидированных отчетов, что упрощает работу с данными. Доступ в режиме реального времени позволяет нам принимать более эффективные бизнес-решения. Мы можем отследить, где транспортируется продукция, если поставщики обеспечивают  своевременную  доставку,  и  информацию  о  различиях  в ценах производителей,  и  все это мы  можем немедленно передать нашим покупателям или менеджерам. Это помогает нам снизить затраты и эффективнее обслуживать наших клиентов и партнеров. Хранилище данных позволило интегрировать и  «подстроить»  некоторые  отчеты  для  более  быстрого  удовлетворения  нужд ЛПР.  Например,  на  то,  что  сейчас  предоставляется  в  одном  отчете,  ранее требовалось 15 отчетов и  16 часов на их создание.

80

ЧАСТЬ  ВТОРАЯ.  ERP  СИСТЕМЫ

Фирмы, задействованные при внедрении Развитие  хранилища данных  потребовало  объединения  в  одной команде различных фирм, и кроме фирмы 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) информационных услуг и ресурсов бизнес-пользователей.

81

ERP  СИСТЕМЫ

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

Обеспечение  хранилищ  данных  кадрами Хранилищу данных требуется команда для поддержания текущих потребностей  пользователей,  системных  изменений  и  обучения. Кроме менеджера программы,  персонал хранилища данных включает  двух  консультантов  (старших  аналитиков-программистов),  двух бизнес-аналитиков информационных услуг,  одного технического инструктора и инженера поддержки. Как заметил Лорен Гранер: «Кевин Конвей  ...  создал целую команду,  которая  поддерживает глобальную инфраструктуру компании Quantum».

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

Различное  оборудование,  ПО  и  консалтинговые  фирмы. Объединять работу нескольких фирм  всегда сложно. Однако Лорен Гранер  (президент  компании  Integral  Results)  полагает,  что  у  каж-

82

ЧАСТЬ ВТОРАЯ. ERP СИСТЕМЫ

дой  из  задействованных  команд  по  реализации  проекта  была  одна общая  цель: Я  думаю,  что обе компании  [Brio  и  Integral  Results]  имеют единую точку зрения на работу с клиентами.  Работа с клиентами означает  понимание  того,  что  нужно  для  получения  хорошего  продукта  — неважно, доставляете вы продукт или внедряете его на предприятии клиента.

Вопросы 1.  Почему  компания  Quantum  использовала  хранилище  данных,  если  у  нее уже была система планирования ресурсов предприятия? 2. Почему компания Quantum использовала сочетание (50/50) информационных услуг и ресурсов бизнес-пользователей? 3.  Что такое виртуальное хранилище данных?  Как вы думаете,  чем оно отличается  от обычного хранилища данных? 4.  Какие расходы требуются на развитие и управление хранилищем данных? Насколько эффективны изменения с учетом затрат и результатов? 5.  Какую  разновидность  партнерства  мы  видим  при  внедрении  хранилищ данных?

6 РЕИНЖИНИРИНГ, «ЗАПУСКАЕМЫЙ  ТЕХНОЛОГИЕЙ», ПРОТИВ  РЕИНЖИНИРИНГА «С  ЧИСТОГО  ЛИСТА» Системы  планирования  ресурсов  предприятий  являются  основным средством сбора и внедрения лучших практик.  Как заметил Хеммер (Hammer  1997):  «SAP — это вынужденный реинжиниринг».  Вицепрезидент  компании  Cap Gemini  сказал  следующее  по  поводу  внедрения ERP систем:  «Редко,  когда не требуется делать реинжиниринг» (Gendron  1996).  Джендрон  называет  ERP  «электронным  воплощением  реинжиниринга». Так как реинжиниринг столь тесно связан с внедрением  ERP систем, фирмы должны обратиться к проблеме выбора между реинжинирингом «с чистого листа» и реинжинирингом, «запускаемым  технологией».

83

ERP СИСТЕМЫ

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

Средства  и технологии  реинжиниринга Идеи  Хеммера  (Hammer  1990)  относительно  реинжиниринга  появились  прежде,  чем  инструменты  для  его  осуществления.  Многие предшествующие попытки реинжиниринга сводились к отказу от существующих процессов, но инструментов осуществления реинжиниринга было мало. Таким образом,  одной из основных причин провала попыток  реинжиниринга было  отсутствие достаточного  количества инструментов для его осуществления. Основное внимание при предшествующем анализе (CSC Index 1994) инструментов,  которые использовались при  реинжиниринге,  уделялось  анализу  ценности  процесса,  сравнительному  тестированию  (benchmarking),  конкурентному  анализу  и функционально-стоимостному анализу.  В таблице 6.1  приведены  итоговые  данные  исследования  CSC  Index  (1994),  проведенного  с  целью понять,  какие «технологии»  были  использованы для  помощи  в  выборе процесса или объектов, нуждающихся в реинжиниринге. Таблица  6.1. Средства,  использованные для  выбора того, что  нужно  подвергать  реинжинирингу Средство Нет Анализ ценности процесса Сравнительное тестирование Конкурентный анализ Функционально-стоимостной анализ Другое

США

Европа

41% 36 34 25 20 16

36% 27 36 28 17 17

Источник:  CSC  Index  (1994).

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

84

ЧАСТЬ ВТОРАЯ. ERP СИСТЕМЫ

ни  проведения  данного  исследования  появились другие  инструменты, разработанные для  реинжиниринга,  некоторые  из  которых были  включены  в  ERP системы.  В  настоящее же  время  ERP является доминирующей  технологией  реинжиниринга.  Но  с  появлением  новых  инструментов вопросы выбора между реинжинирингом, «запускаемым технологией»,  и  реинжинирингом  «с чистого листа» становятся актуальными.

Что такое реинжиниринг, «запускаемый технологией», и  реинжиниринг «с чистого листа»? Фактически,  реинжиниринг  осуществляется  с  использованием целого  спектра  подходов:  от  подхода с  «запускающей  технологией» до реинжиниринга «с чистого листа».

Реинжиниринг, «запускаемый (вынуждаемый) технологией» При реинжиниринге, «запускаемом технологией», прежде чем системы,  объекты  или  процессы  будут  подвергнуты  реинжинирингу,  для его  осуществления  выбирается  определенная  технология  (или  их  набор). В результате выбор объектов реинжиниринга — функция определенной технологии, выбранной для его проведения. Например, если такая технология — это ERP система, то сначала выбирают ERP систему, а только потом МОПы предприятия из тех, которые она может поддерживать. Следовательно, реинжиниринг осуществляет ПО ERR ERP система  может  преобразовывать  все  необходимые  основные  документы (виртуальные или на бумаге) в выбранный вид, так как этот вид задается ПО. В результате реинжиниринг называют «запускаемым технологией». Так как внедрение не меняет ПО, время и стоимость его внедрения при реинжиниринге, «запускаемом технологией», будут ниже. Реинжиниринг,  «запускаемый технологией»,  называли по-разному.  Gemini  Consulting  (1996,  с.  7)  называет одновременный  реинжиниринг  и  внедрение  ERP  системы  «совместной  трансформацией». Технология  не  только  придает  определенные  возможности  реинжинирингу,  но и ограничивает его теми опциями,  которые может поддерживать ERP система. Таким образом, мы будем называть его также «ограниченным» реинжинирингом.

Реинжиниринг «с чистого листа» При реинжиниринге «с чистого листа» проектирование системы действительно начинается с «чистого листа». Процессы подвергают -

85

ERP  СИСТЕМЫ

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

Между двумя методами Во  многих проектах реинжиниринга однозначный  выбор  между реинжинирингом  «с чистого листа»  и  реинжинирингом,  «запускаемым  технологией»,  не  делается:  вместо  этого  используются  они оба. Обычно реинжиниринг проводят или с большим уклоном в сторону либо  реинжиниринга «с  чистого листа»,  либо  реинжиниринга, «запускаемого технологией», задействуя эти методы в большей или меньшей степени. Это важные вопросы, и мы вернемся к ним в главе 9, в которой обсудим, что должно быть изменено: ПО или организация.

Преимущества реинжиниринга, «запускаемого технологией» Существует множество преимуществ этого вида реинжиниринга, каждое  из  которых связано с  использованием  возможностей технологий,  используемых  при  реинжиниринге.  Некоторые  из  преимуществ  использования  ERP  системы  в  качестве  средства  реинжиниринга иллюстрирует случай с компанией Geneva Steel.

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

86

ЧАСТЬ  ВТОРАЯ.  ERP СИСТЕМЫ

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

Средства, помогающие рационализировать и объяснить усилия по реинжинирингу При  использовании  в  качестве  средств  реинжиниринга  ERP системы  также  предоставляют  «причину»  реинжиниринга:  «Нам нужно  провести  реинжиниринг  для  того,  чтобы  внедрить  SAP». Компания  Geneva  Steel  ясно  дала  понять,  что  она  будет  внедрять SAP, и что это изменит организацию: «Люди,  наконец, поняли, что, нравится  это  или  нет,  но  это должно  случиться».  Предполагалось, что  внедрение  системы  SAP  обеспечит  новую  структуру  организации.

Средства, помогающие создавать решения лучшие, чем были бы созданы иными способами Системы планирования ресурсов предприятия могут помочь направить усилия по реинжинирингу на принятие лучших решений, чем это  можно  было  бы  достичь  иными  способами.  Это  происходит  в случае,  если  необходим  опыт для  принятия  лучших  решений,  а  команда развития  имеет ограниченный опыт.  Лучшие практики,  заложенные  в  ERP  системы,  дают  знание  о  процессах,  которое  можно применить,  что  может  смягчить  проблему отсутствия  опыта.  В  случае  с  компанией  Geneva  Steel  система  SAP  уже  была  использована большим количеством сталелитейных предприятий. Таким образом, лучшие практики многих из них были заложены в ПО еще до внедрения  системы  компанией  Geneva  Steel.  Следовательно,  Geneva  Steel могла найти лучшие решения по сравнению с теми, которые она могла бы принять сама.

87

ERP  СИСТЕМЫ

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

Выбранная форма реализации процесса осуществима данным ПО Возможно, самой важной причиной использования метода реинжиниринга, «запускаемого технологией», является то, что формы реализации  процессов  выбираются  из  числа  допустимых.  ERP  система спроектирована для приспосабливания каждого набора форм. Далее, выбор из заданного набора форм поддерживает проектирование процессов, которые могут взаимодействовать с другими процессами, выбранными для использования в системе. Таким образом, осуществимость критична для конкретных процессов и для их взаимодействия с другими  процессами.  Например,  компания  Geneva  Steel  выбирала лучшие  практики  из  портфеля  системы  SAP,  и  это  означает,  что  выбранные формы  реализации  процессов будут осуществимы.

Есть свидетельство того, что процесс будет работать в организации Если  процесс,  соответствующий лучшей  практике,  является  частью ERP системы или другой базы знаний лучших практик,  это свидетельство  того,  что  он  действительно  работает.  То,  что  процесс  включен  в  лучшие  практики,  обычно  означает,  что  некая  организация  успешно его внедрила. Это одна из основных причин того, что компания Nestle  решила  внедрить  набор  процессов  и  объектов лучших  практик из  БД лучших  практик,  предоставленной  консультантом,  и  из лучших практик компании, содержащихся в ERP системе. Так как система SAP была  использована  несколькими  сталелитейными  компаниями,  было достаточно свидетельств,  что она будет работать и  в Geneva Steel.

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

88

ЧАСТЬ ВТОРАЯ. ERP СИСТЕМЫ

внедрения  была  разумной.  Например,  недавняя  разработка  SAP  — «ASAP» направлена на увеличение числа внедрений SAP и рентабельную  работу.  В  целом,  затраты  на систему,  относящиеся  к  внедрению существующих  процессов  (например,  лучшие  практики  в  ERP  системе),  могут быть  разумными.

Процессы могут быть внедрены в течение конкретного срока Разработчики также пришли к пониманию важности возможности внедрения ERP системы в течение конкретного срока. Как уже было сказано,  компания SAP разработала ASAP,  нацеленный  на то,  чтобы внедрения проводились в разумные сроки (например, девять месяцев). Таким образом, многие процессы, предоставляемые ERP, могут быть внедрены в течение приемлемого времени.

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

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

Преимущества реинжиниринга «с чистого листа» Реинжиниринг «с чистого листа» имеет преимущества по сравнению  с  реинжинирингом,  «запускаемым  технологией»  (например, ERP), благодаря тому, что он не зависит ни от одной из определенных

89

ERP  СИСТЕМЫ

технологий.  Пример  реинжиниринга  «с  чистого  листа»  представляет проект «Дельта»  компании Geneva Steel  (см.  приложение 3-1).

Не ограничен ни одним из определенных инструментов Реинжиниринг «с чистого листа» не ограничен ни одним из определенных  инструментов.  Например,  проект  «Дельта»  компании Geneva  Steel  не  имел  при  внедрении  каких-то  начальных  предпочтений, так как не было инструментов,  способствующих реинжинирингу. Таким образом, при реинжиниринге «с чистого листа» для внедрения может  быть  использован  целый  набор  инструментов.  Так  как  любое средство  реинжиниринга  накладывает  ограничения  и  привносит определенные  предпочтения,  использование  нескольких  средств  может иметь значительные  преимущества  по  сравнению  с  использованием одного единственного инструмента.

Не ограничен знанием о событиях и процессах Хотя  ERP  системы  могут  использовать  ряд лучших  практик,  они также  ограничены  своей  БД лучших практик.  Фирмы,  имеющие уникальные процессы,  создающие ценность,  часто следят за тем,  чтобы они  не  были  включены  в  число  процессов,  которые  попадают  в  БД консультантов  или  ERP  системы.  Из  обсуждения  с  компанией  Price Waterhouse  выяснилось,  что  некоторые  из  их  клиентов  попросили, чтобы  информация  об  их лучших  практиках  не  включалась  в  БД лучших  практик.  Некоторые  клиенты  даже  попросили  компанию  Price Waterhouse  исключить  общедоступные  знания  из  этих  БД.  Таким  образом,  когда  организация  использует  БД  лучших  практик,  та  может включать вовсе не все лучшие практики.

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

90

ЧАСТЬ ВТОРАЯ.  ERP СИСТЕМЫ

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

Реинжиниринг рассматривается отдельно от внедрения технологии Часто  внедрение  ERP  систем  критиковали  за то,  что  оно  слишком дорого и требует слишком большого времени.  В некоторых ситуациях  эти  недостатки  возникают  не  собственно  из-за  внедрения ERR а из-за того, что сюда включается и внедрение ПО, и реинжиниринг.  При  проведении  реинжиниринга  «с  чистого листа»  нет сомнений, где — реинжиниринг, а где — внедрение технологии. Исследование  реинжиниринга  бизнес-процессов  (BPR)  и  ERR проведенное Gemini  Consulting  (1996),  показало,  что только  16%  рассмотренных фирм  планировали  провести  реинжиниринг  бизнес-процессов  до  внедрения  ERP  системы.  Однако  после  внедрения 35% фирм сказали, что стоит использовать стратегию проведения реинжиниринга бизнес-процессов до внедрения ERR Таким образом, существует  свидетельство  того,  что  фирмы  нуждаются  в  первоначальном проведении реинжиниринга и только затем — во внедрении ERR

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

* Имеется в виду,  не быть привязанной к конкретному программному продукту  (прим.  науч.  редактора).

91

ERP СИСТЕМЫ

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

Недостатки реинжиниринга, «запускаемого  технологией» Недостатки  реинжиниринга,  «запускаемого  технологией»,  по большей  части,  прямо  противоположны  преимуществам  подхода к  реинжинирингу  «с  чистого  листа».  Так  как  они  уже  подробно обсуждались,  вышеупомянутые  недостатки  здесь  просто  перечислены. •  Реинжиниринг  ограничен  определенным  инструментом,  использованным  при  внедрении. •  Реинжиниринг  ограничен  знанием  об  объектах  и  процессах, включенных в  инструмент. •  Развитие системы  может ограничиваться технологией. •  К выбранной форме  реализации  процессов  имеют доступ другие фирмы. •  Могут появляться сомнения:  это внедрение технологии или реинжиниринг? •  Для  некоторых установок  может  не  оказаться  лучших  практик, что ограничивает их использование.

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

92

ЧАСТЬ ВТОРАЯ. ERP СИСТЕМЫ

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

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

Крупные фирмы Размер  фирмы  влияет  на  использование  метода  реинжиниринга «с  чистого  листа»  —  более  крупные  фирмы  имеют  большое  число причин для  использования данной  стратегии.  Они: •  Имеют  ресурсы  для  осуществления  такого  реинжиниринга. •  Часто  являются  лидерами  в  своей  сфере  и,  как  следствие, имеют  запас  во  времени. •  Существует  большая  вероятность,  что  они  будут  использовать процессы  в  качестве  базиса  для  получения  стратегического преимущества. •  Существует  большая  вероятность  того,  что  им  понадобится уникальное  решение.

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

93

ERP  СИСТЕМЫ

тия  особо  высококвалифицированных  специалистов,  которые  иначе могли бы заниматься другими видами корпоративной деятельности. Компания  Procter  &  Gamble  продемонстрировала  важность «больших  карманов»  в  рамках  своей  работы  по  осуществлению реинжиниринга  процессов  управления  цепочками  поставок  (см. McKenney  and  Clark  1995).  Procter  &  Gamble  использовала  большое  число  различных  форм  реализации  процессов  в  ряде  компаний-клиентов  для  развития  своей  системы  управления  цепочками поставок,  которую  она,  в  конечном  итоге,  отдала  компании  IBM. Начав  с  обмена  электронными  данными,  Procter  &  Gamble  развила  систему,  в  которой  она  осуществляла  мониторинг  запасов  клиентов  и  размещала  заказы  для  них,  используя  прямое  обращение к  их  БД.  Такая  эволюция  потребовала  много  времени  и  вложений и  оказалась  бы  невозможной  без  значительных  ресурсов.

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

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

94

ЧАСТЬ ВТОРАЯ. ERP СИСТЕМЫ

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

Фирмы, ищущие уникальное решение Решения  реинжиниринга,  «запускаемого  технологией»,  могут быть  скопированы другими,  и  лучшие  практики  ERP  систем,  внедренные  в  одной  фирме,  могут  быть  реализованы  и  в  других  фирмах.  Напротив,  решения  реинжиниринга  «с  чистого  листа»  обычно распространяются  не  так  быстро.  Если  организации  нужно  уникальное  решение,  то  его  скорее  предоставит  реинжиниринг «с  чистого  листа».

Кто должен использовать (использует) метод реинжиниринга, «запускаемого технологией»? Факторы,  о которых мы говорили  выше,  могут также использоваться  для  определения  того,  какие  фирмы  должны  применять  решения,  «запускаемые  технологией».  Например,  малые  фирмы обычно  имеют  небольшие  бюджеты  и  стандартные  процессы,  которые  ограничивают  их  способность  и  необходимость  проводить большой  реинжиниринг «с чистого листа».  Так,  компания Accugraph (см.  Koch  1996)  внедрила «предварительно структурированный»  пакет  компании  SAP  «Special  Delivery».  Она  сосредоточилась  на  финансовом  пакете,  консультантах и  отказалась от  какого-либо  реинжиниринга вне  возможностей  наперед указанных форм  реализации процессов.

Какой  подход используют чаще всего? В  исследовании  Gemini  Consulting  (1996)  была  собрана  эмпирическая  информация  по  одновременному  и  не  одновременному осуществлению  реинжиниринга  бизнес-процессов  и  внедрения SAP.  Фирмам  были  заданы  вопросы  о  (а)  реально  использованной  стратегии  и  (б)  о  том,  какую  стратегию  они  выбрали  бы,  если  бы  могли  начать  заново.  Хотя  данные  относятся  к  определенной  системе  (SAP),  результаты  могут  быть  распространены  и  на другие  ERP  системы.  Результаты  исследования  представлены  в таблице  6.2,

95

ERP  СИСТЕМЫ

Таблица  6.2.  Реинжиниринг бизнес-процессов  и  SAP  R/3 Список А:  Оригинальная  стратегия внедрения BPR и одновременное внедрение SAP R/3  BPR до внедрения SAP R/3  BPR после внедрения SAP R/3  BPR до и после внедрения SAP R/3  1  BPR не был нужен 

48% 16% 3% % 33%

Список Б: Что бы вы выбрали после внедрения? BPR и одновременное внедрение SAP R/3  BPR до внедрения SAP R/3  BPR после внедрения SAP R/3  BPR до и после внедрения SAP R/3  BPR не был нужен 

51% 35% 3% 1 % 10%

Источник:  Gemini  Consulting  (1996).

Gemini Consulting установила,  что  в обоих случаях только 4% компаний либо  осуществляли,  либо захотели  бы  в  результате  полученного  опыта  осуществить  реинжиниринг  бизнес-процессов  после  внедрения  SAP или до и  после  внедрения.  Напротив,  96%  или  не осуществляли  реинжиниринг  вообще,  или  делали  это  до  внедрения  SAP, или  одновременно  с  внедрением.  Только  16%  запланировали  реинжиниринг до внедрения SAP,  а позже 35% говорили,  что они  выбрали бы эту стратегию. И в списке А, и в списке Б реинжиниринг, «запускаемый  технологией»,  является  доминирующей  стратегией.  При  сравнении  списков  А  и  Б  видно,  что  самый  большой  рост  происходит  в пользу  выбора  реинжиниринга  «с  чистого  листа».  Самым  же  значительным  образом уменьшилось число фирм  (с 35% до  10%),  считающих,  что  реинжиниринг  не  нужен.  Таким  образом,  видно,  что  фирмы должны  предусматривать  проведение  реинжиниринга  при  внедрении такой ERP системы,  как R/3.

Резюме В данной  главе были  исследованы  реинжиниринг «с чистого листа»  и  реинжиниринг,  «запускаемый  технологией».  Преимущества  реинжиниринга  «с  чистого листа»: •  Фирмы  не ограничены  конкретными  инструментами. •  Фирмы  не ограничены  отсутствием знаний о лучших практиках. •  Будущие  версии  не  ограничиваются  технологиями.

96

ЧАСТЬ ВТОРАЯ. ERP СИСТЕМЫ

•  Фирмы  могут  создать  уникальные  формы  реализации  процессов. •  Реинжиниринг  не  смешивается  с  внедрением  технологии. •  Он  может  быть  единственным  выходом  для  создания  процессов  при  использовании  новых технологий. С  другой  стороны,  реинжиниринг,  «запускаемый  технологией», может: •  структурировать усилия  по  реинжинирингу, •  рационализировать  и  объяснить  необходимость  приложения усилий  по  реинжинирингу, •  создавать  лучшие  решения, •  ограничить  форму  реализации  процессов, •  ограничить усилия  по  поиску формы  реализации  процессов, •  гарантировать,  что  выбранная  форма  реализации  процессов будет  работать, •  создать  более  рентабельные  формы  реализации  процессов, •  гарантировать  внедрение,  ограниченное  во  времени, •  помочь  фирмам  избежать  необходимости  использования  множества  консультантов  с  их  отчетами. Предприятия  должны  выбрать  метод,  соответствующий  их  потребностям  и  ресурсам  в  процессе  реинжиниринга.  В  целом,  можно предположить,  что  фирмы,  использующие  метод  реинжиниринга  «с чистого  листа»,  кроме  того,  что  они  крупные,  имеют  также  «большие карманы»,  не  имеют  ограничений  во  времени  и  имеют  или  используют  уникальные  процессы  в  качестве  основы  конкурентного  преимущества.  Напротив,  использование  метода  реинжиниринга,  «запускаемого  технологией»  более  характерно  для  фирм: •  с  ограниченным  бюджетом, •  ограниченных  во  времени, •  с  относительно  стандартными  процессами. В любом  случае фирмы должны  понимать,  что  некоторый  реинжиниринг  будет  необходим.  Одно  из  исследований  показало,  что  большинство  фирм  выбрали  одновременный  реинжиниринг  и  внедрение 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.

97

ERP СИСТЕМЫ

Gendron.M.  (1996).  «Learning  to  Live  with  the  Electronic  Embodiment  of Reengineering». Harvard Management Update, November, pp. 3-4. Hammer,  M.  (1990).  «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. Koch.C.  (1996). «Flipping the Switch». CIO Magazine, June  15. McKenney,  J.,  and  Clark,  T.  (1995).  «Procter  &  Gamble:  Improving  Consumer Value through  Process  Redesign».  Report no.  9-195-126,  Harvard  Business School, Cambridge, MA.

98

Часть третья ЖИЗНЕННЫЙ  ЦИКЛ ERP СИСТЕМ 7 ПРИНЯТИЕ  РЕШЕНИЯ О  ВНЕДРЕНИИ  ERP  СИСТЕМЫ

В  данной  главе  анализируются  различные  случаи,  ассоциируемые  с  принятием  решения  по  внедрению  ERP системы.  В  частности здесь исследуются  следующие четыре  вопроса; 1)  Какими  могут  быть  бизнес-основания,  определяющие,  внедрять или не внедрять ERP систему,  и какие из них являются наиболее распространенными? 2)  Как  можно  использовать  бизнес-основания  для  облегчения разработки  формы  реализации  процессов  или  оценки  успешности внедрения? 3)  Как фирмы оценивают основания:  в денежном  или в ином  выражении? 4)  Как в конечном итоге фирма принимает решение о внедрении ERP  системы?

99

ERP  СИСТЕМЫ

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

Технологические обстоятельства Организации использовали множество технологических оснований  для  оправдания  выбора  ERP  системы.  В  проведенном  недавно исследовании компании Deloitte & Touche фирмам был задан вопрос, почему они решили внедрить ERP систему.  Результаты исследования представлены в таблице 7.1. Таблица  7.1.  Технологические  мотивы Мотив

Системы не решают «Проблемы 2000-го года» Несопоставимые системы Низкое качество систем / представления информации Бизнес-процессы или системы не интегрированы Трудности интеграции приобретенных компаний Устаревшие системы Невозможность поддерживать рост

100

Число Процент фирм от общего числе

42 37

27 24

26

17

19

12

12 11 8

8 7 5

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

«Проблема 2000-го года» Одной  из  наиболее  распространенных  причин  адаптации ERP-систем  была  «Проблема  2000-го  года»  («Y2K»).  Фирмы столкнулись  с  необходимостью  модернизировать  традиционные программы,  чтобы  избежать  возможных  сложностей,  вызванных «Проблемой  2000-го  года».  Во  многих  случаях  эта  задача  оказалась  трудноразрешимой.  Так  как  программисты  уже  не  работали, а  достаточной  документации  по  программам  не  было,  о  многих из  этих  систем  было  мало  что  известно.  Кроме  того,  речь  шла  о сотнях  программ. Системы планирования ресурсов предприятий, казалось, предлагают относительно быстрое и простое решение для многих фирм. Такие  пакеты  программ,  как SAP,  могли  решить  «Проблему 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-го года».

101

ERP  СИСТЕМЫ

Несопоставимые системы Несопоставимые  компьютерные  среды  ограничивают  возможность  фирм  интегрировать  различные  бизнес-единицы,  деятельность  которых  поддерживается  различными  типами  компьютеров. ERP системы предоставляют широкий выбор ПО для работы в единой вычислительной  среде. Более того,  многие фирмы  перешли  на технологию  клиент-сервер для того, чтобы покончить с системами на основе мейнфрейма и сопутствующими технологиями  (см.  например,  Vaughn  1996).  Чтобы они  смогли  это  реализовать,  им  понадобилось  «клиент-серверное» ПО.  Однако,  совершив переход к технологии клиент-сервер в  начале 90-х гг., фирмы обнаружили, что ПО для работы в этой среде было мало  доступным.  Среди  ограниченного  числа  доступных  программных продуктов были  ERP системы,  такие как SAP  R/3. Примеры.  Конфигурация  информационной  системы  компании Geneva Steel со временем эволюционировала в несколько неоднородных систем.  Как сказал Джозеф Кеннон (СЕО компании Geneva Steel): У нас есть... мейнфрейм ... и ... примитивная бухгалтерская система ... У нас много различных типов компьютеров. Им сложно общаться друг с другом. У нас большое количество мини-компьютеров различных типов с различным программным обеспечением ... Наша система — это выход из этого ада. Приведем  другой  пример  (Stevens  1998):  компания  Owens Corning  перешла  к  стандартной  клиент-серверной  архитектуре,  используя интернет-протоколы (IP) и имеющееся в наличии готовое ПО с целью уменьшения стоимости системы и владения сетью.  Это бизнес-основание было  использовано  компанией  Owens  Corning  наряду с другими основаниями, описанными ниже.

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

102

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ 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:

103

ERP  СИСТЕМЫ

Нам нужно было видеть, как работают наши процессы... Процессы должны меняться. Как компания, приобретшая множество других компаний,  Browning-Ferris не имела унифицированных процессов.  Одной из стоящих перед нами задач было сделать так, чтобы 500 наших подразделений использовали стандартные процедуры. (Bailey 1999)

Оценка технических оснований Несмотря  на  все  их  количество,  технические  основания  обычно можно  сделать  измеримыми  на уровне ответов  «да-нет».  Например, справляется  приложение  с  «Проблемой  2000-го  года»  или  нет;  можно интегрировать сбор данных или нет;  могут системы поддерживать рост  или  нет.  Технические  основания  могут  быть  достаточными  для замены системы, но они мало говорят о том, какая конфигурация системы  нужна.

Основания со стороны бизнес-процессов Организации использовали несколько оснований со стороны бизнес-процессов для оправдания  выбора  ERP системы.  Например,  организация  могла бы  назвать потенциальной  причиной  перехода к ERP системе сокращение незавершенного производства на 40%. В исследовании, проведенном Deloitteand Touche, фирмы также спрашивали, какие  изменения  в  бизнес-процессах  помогают  определить  необходимость внедрения ERP системы. Основания со стороны бизнес-процессов, по большей части, состоят в улучшении продуктивности организации или снижении расходов.  Результаты исследования представлены в таблице 7.2.  При этом фирмы смогли назвать не одну причину и  положительный  результат  внедрения.  В дополнение  к этой таблице в  данном  параграфе  обеспечивается  «погружение  в  данные»  множества бизнес-оснований и приводятся конкретные примеры. Таблица 7.2. Ожидаемые бизнес-преимущества от внедрения  ERP Преимущество

Сокращение  персонала Сокращение запасов Сокращение расходов на ИТ Повышение производительности Сокращение цикла управления заказами Управление денежными средствами Прибыль/доход Снабжение Завершение финансового цикла Техническое обслуживание

104

Кол-во фирм 44 42 27 23 19 16 15 12 10 8

Процент от общего числа 20 19 13 11 9 7 7 6 5 4

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

Сокращение персонала и расходов на ИТ Внедрение  ERP систем часто связывают с  последующим сокращением  персонала,  особенно  в  бухгалтерии  и  подразделениях  информационных систем. Пример.  Ожидается,  что  внедрение  SAP  компанией  Geneva Steel отразится на количестве бухгалтеров и персонала подразделения  информационных  систем.  Как  сказал  СЕО  компании  Джозеф Кеннон: В первую очередь, у нас будет меньше бухгалтеров и, возможно, меньше администраторов информационных систем. Потому что одна из вещей, которые мы рассматриваем, это сокращение части этих функций. Большую часть того, что делают бухгалтеры ... ненужно будет делать, когда будет внедрена система SAP. В  результате  компания  Geneva  Steel  предполагала  сократить свой штат сотрудников отдела информационных технологий примерно с 80 до  12 человек, а штат бухгалтерии с 60 до  10 человек.

Повышение производительности Шаф (Schaff  1997) заметил,  что, так как повышение производительности всегда будет в моде, разработчики ERP будут иметь постоянный  спрос  на  свою  продукцию.  Не  удивительно,  что  некоторые фирмы принимают решение о внедрении ERP системы с целью улучшения конкретных аспектов производительности. Пример.  Компания  Owens  Corning  приняла  решение  о  внедрении ERP системы с целью повышения производительности. Как отметил  Майкл  Редклиф  (вице-президент  по  интернет-обслуживанию  и СЮ компании Owens Corning),  когда проект внедрения  ERP  начался: «Чтобы оправдать [затраты на]  проект,  мы изначально нацелились на ощутимые результаты,  которые руководство сможет увидеть и которые  мы  сможем  четко  сформулировать  и  выполнить»  (см.  Stevens 1998). Ожидалось, что доходы от внедрения достигнут 50 млн. долларов, в том числе, благодаря: • уменьшению расходов на 1 % при закупках сырья благодаря положительному  эффекту  масштаба; •  уменьшению  расходов  на  1%  благодаря  сокращению  количества складов и более низкой стоимости перевозок; •  улучшению  обслуживания,  ориентированного  на  обеспечение надежности, что обеспечит меньшие расходы на обслуживание предприятия.

105

ERP  СИСТЕМЫ

Завершение финансового цикла Чтобы обеспечить качество управленческих решений,  необходима своевременная информация.  Одним  из основных средств в этом направлении является количество времени, требующегося на завершение финансового цикла. Таким образом, сокращение времени на завершение финансового цикла может стать важной причиной внедрения  ERP  системы.  Например,  компания  X  (см.  приложение  12-1) хотела при внедрении ERP системы сократить ежемесячный процесс завершения финансового цикла с 24 до 6 дней.

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

Стратегические основания Системы  планирования  ресурсов  предприятий  предоставляют возможность  внедрения  различных  стратегий,  которые  существующее  ПО  не  поддерживает.  Эти  стратегии  выходят  за  рамки улучшения  конкретных  бизнес-процессов.  Стратегические  основания  позволяют  сфокусироваться  на  целях  улучшения  уровня  обслуживания  клиентов  или  качества  вообще  —  вопросах,  обычно не  связываемых  с  системами  обработки  деловых  операций. Стратегические  основания  могут  привести  к  внедрению  ERP  системы  как  информационной  магистрали,  которая  может  быть  использована  в  качестве  базиса  электронной  коммерции.  Эти  вопросы  рассмотрены  в  главе  14. Примеры.  Чтобы  повысить  уровень  обслуживания  клиентов, компания Quantum выбрала Oracle Applications.  Решение о внедрении ERP системы было основано на том, что система могла выполнить эту клиенто-ориентированную стратегию, и на конкретных возможностях системы.

106

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

Приведем другой пример.  Компания Cisco также смотрит на затраты на ИТ с точки зрения стратегии.  Как сказал президент компании Джон  Могридж:  «Мы с самого  начала не думали об их [ИТ]  возможностях в терминах долларов.  Мы считали,  что необходимо обеспечить качественное обслуживание,  и  именно поэтому мы  внедрили программу» (Stevens  1998).

Конкурентные основания Хотя  технологические  основания  и  основания  со  стороны  бизнес-процессов важны, одна из основных причин внедрения ERP системы — это то,  что у конкурентов она уже есть.  Как сказал  Брюс  Ричардсон  из AMR  Research:  «ERP часто покупают для того,  чтобы просто остаться в бизнесе». Если  у  конкурентов  есть  ERP  система,  а у  вас  —  нет,  они  могут иметь (например) более лучшие возможности для обслуживания клиентов  или  быстрее  снабжать  информацией  своих  менеджеров,  особенно  если  они  решат  внедрить  систему  для  достижения  именно этой цели. Таким образом, принятие на вооружение ERP системы одной фирмой  может привести к необходимости для ее прямых конкурентов вооружиться подобной системой. Заявление  «у  конкурентов  это  есть»  в  качестве  основания может  породить,  по  крайней  мере,  два  абсолютно  разных  подхода.  С  одной  стороны,  фирма  может  просто  заявить,  что  у  ее  основных  конкурентов  система  есть,  и  поэтому  у  нее  она  тоже должна  быть.  С  другой  стороны,  фирма  может  остановиться  на вопросе,  почему  важно  то,  что  у  конкурентов  есть  именно  эта система,  и  исследовать,  какие  специфические  выгоды  могут  быть получены  при  аналогичном  выборе. Пример.  Предположим,  что  ваша  фирма  —  конкурент  компании  Quantum,  которая  решила  внедрить  ERP  систему,  чтобы повысить  уровень  обслуживания  клиентов.  В  частности,  ERP  позволяет  ей  обеспечивать  клиентам  опцию  «доступно  по  обещанию»  (available  to  promise,  ATP)  —  уникальную  возможность,  которая  позволила  компании  гарантировать,  что  запасы  могут  быть распределены  между  конкретными  покупателями  (обычно  между самыми  крупными  и  лучшими  покупателями).  Так  как  Quantum вооружилась  системой  раньше,  вы  как  конкурент  могли  бы  просто  наблюдать,  было  ли  внедрение  программы  успешным  и  работает  ли  АТР  так,  как  предполагалось.  Когда  ПО  заработало,  вы могли  подумать  о  его  внедрении  в  своей  фирме,  чтобы  предоставить  клиентам  те  же  возможности.

107

ERP  СИСТЕМЫ

Компания  Western  Digital  —  один  из  основных  конкурентов компании  Quantum.  24  июня  1996  г.  отдел  прикладных  систем корпорации  Oracle  объявил,  что  «несколько  компаний  работали  с Oracle  Applications  в  течение  квартала,  включая  Silicon  Graphics, Inc.  и  корпорацию  Quantum,  причем  обе  эти  компании  успешно провели  крупномасштабные  внедрения».  Кроме  того,  в  это  же время  отдел  прикладных  систем  корпорации  Oracle  объявил,  что «среди  новых  клиентов,  появившихся  за  этот  квартал,...  компания Western  Digital...»

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

108

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

Метод чистой  приведенной  стоимости (Net  present value,  NPV) Хотя  ранее  каждая  категория  оснований  была  рассмотрена  отдельно,  для  анализа всех расходов  и  выгод,  как и  при  любом  инвестировании,  может  быть  использован  метод  NPV  .  Вегл  (Wagle  1998, с.  132) предлагает для этого следующие шаги: 1.  Смоделировать ежегодную  экономию средств  от сокращения расходов,  которая  могла  бы  быть  достигнута  без  использования  на предприятии ERP системы в качестве базовой. 2.  Смоделировать ежегодную экономию средств,  которая  могла бы быть достигнута с использованием  ERR  Сюда должны быть включены  сэкономленные  средства,  как  не  зависящие  от  ERP  системы (случай шага 1), так и те, которые экономятся благодаря ее использованию. 3.  Вычесть  ежегодную  экономию  средств  для  случая  шага  1  из экономии  средств для  случая  шага  2  (с  ERP)  и  рассчитать  NPV остаточного  движения  денежных  средств.  Положительное  значение  NPV укажет на то,  что вы,  вероятно, должны продолжить внедрение ERR 4.  Если  на  шаге  3  получена  положительная  NPV,  проведите  анализ чувствительности, чтобы убедиться в том, что бизнес-доводы достаточно устойчивы,  чтобы  противостоять уменьшению и  перерасходу средств. 5.  Перераспределите  все  расходы  на  внедрение  ERP  системы между конкретными бизнес-единицами, чтобы они могли включить их в свои  планы.  Убедитесь,  что  каждая бизнес-единица несет ответственность за  реализацию  намеченных  изменений.

Оценка  оснований:  денежные  цели  против  неденежных Независимо  от  вида  бизнес-основания  для  решения  о  внедрении  ERP  системы  многим  фирмам  требуется  некоторая  внутренняя  оценка  (денежная  или  неденежная)  затрат  и  выгод  от  ее внедрения.

*  Этот  метод  основан  на  сопоставлении  величины  исходной  инвестиции  с общей  суммой  дисконтированных  (приведенных  к  настоящему  времени)  чистых денежных  поступлений,  генерируемых  ею  в  течение  выбранного  срока.  Чистая приведенная  стоимость  позволяет  определить  приемлемость  инвестиционного проекта  (прим.  науч.  редактора).

109

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». Такое  мнение  могло  возникнуть  в  результате рассмотрения других  вопросов.  Например,  это  утверждение  могло  быть  результатом

110

ЧАСТЬ ТРЕТЬЯ, ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

Достоверные данные против недостоверных «Качество» данных,  на которых строится основание выбора,  может зависеть от вида основания, создающего данные оценки. Например, как сказал Барри Сейд из компании Litton Data Systems: «Я сделал так,  чтобы  наши  служащие  шире  изучали  ROI  [на  различных аспектах повышения производительности],... но это были недостоверные данные». Кроме того, на покупку системы корпорацией может повлиять качество данных.  Как сказал Сейд:  «Данные о «Проблеме 2000-го года» были достоверными. Они [топ менеджмент] поверили этим данным».

Использование оценки Как видно из примера компании Litton Data Systems,  измерение затрат и  результатов было основано на текущем  ERP-проекте.  Однако  в  некоторых  случаях  ROI  используется  как  ориентир  для  других проектных инвестиций. Джон Мортридж (глава компании Cisco) отметил:  «Обычно мы  не выполняем традиционный анализ ROI до осуществления инвестиций  и запуска ИТ-программы.  Мы изучаем ROI после  инвестиций  и  используем  это  как  ориентир  для  направления  и размеров будущих инвестиций в ИТ» (Stevens  1998). В любом случае, оценка проектных расходов необходима для того, чтобы оценить общую успешность внедрения и обеспечить «актуальность» начального бюджета. Эти проектные затраты должны начинаться с расходов на принятие решения «стоит или нет внедрять ERP систему» и продолжаться в течение всего жизненного цикла проекта.

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

111

ERP  СИСТЕМЫ

Роль топ-менеджмента Какова  роль топ-менеджмента  в  принятии  решения  о  внедрении  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-го  года»), •  конкурентные основания (чтобы остаться в бизнесе), •  основания со стороны бизнес-процессов (вопросы эффективности и продуктивности), • стратегические основания (обслуживание клиентов и качество). Первые  две  группы  оснований  обеспечивают  ограниченную помощь  в  выборе  процессов,  необходимых  для  внедрения  системы.  Однако,  если  последние  две  группы  оснований  также  ис-

112

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

Литература Baatz, E. (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. Shaff, W.  (1997). «PeopleSoft Takes a Hit,  But Watch for Comeback».  Information Week, April 28. Stevens, T.  (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 системой,  разработанной сторонней фирмой,  вместо того,  чтобы самостоятельно разрабатывать,  внедрять  и  поддерживать  систему.  Во-вторых,  все

113

ERP  СИСТЕМЫ

подразделение  обработки  данных  может  использоваться  по  схеме аутсорсинга*,  и  решение о  внедрении  ERP системы  принимается  в согласии с фирмой, которая предоставляет услуги такого ИТ-подразделения.

Использовать ERP, разработанную сторонней фирмой? При выборе ERP системы, одним  из важнейших вопросов является  вопрос,  должна  ли  быть  система  собственной  или  готовой? Компании  Oracle  (Stein  1998a),  PeopleSoft  (Stein  1998a),  J.D.  Edwards (Stein  1998b)  и SAP (Sweat and  Stein  1998) — все создают готовое  ПО  ERP. Чтобы донести продукт до клиентов,  при создании готового ПО необходимо  сотрудничество  с  партнером.  Например,  SAP  America сотрудничает с Andersen Consulting, AT&T Customer Care и EDS (Sweat and  Stein  1998).  Компания  J.D.  Edwards  сотрудничает  с  World Technology Services, IBM Global Services и другими. Потенциальное  преимущество  готовых  систем  очевидно.  Как сказал генеральный подрядчик (Stein  1998b), заключивший контракт на 60 млн. долларов с фирмой J.D. Edwards: «Нам был необходим пакет программ бухгалтерского учета,  но  мы  не хотели совершать огромные  инвестиции  в  программное  обеспечение  и  оборудование. Заключив этот контракт, мы избежали огромных финансовых затрат и минимизировали  потребность  в  администраторах  информационных систем». Однако есть  и  недостатки.  Например,  как заметил  вице-президент  по  ИТ компании  Fujitsu  Microelectronics:  «Ключевой  проблемой является проблема соответствия нашего программного обеспечения бизнесу и оптимальности приложений для нашей компании. Я неуверен, что продукция независимых разработчиков решит эту проблему» (Stein 1998a).

Использование услуг подразделения обработки данных сторонней компании В  целом,  вопрос,  когда  фирма  должна  начать  работать  по  обработке  данных  со  сторонними  компаниями,  не  входит  в  круг  проблем,  затрагиваемых  в  данной  книге.  Однако  нам  важен  вопрос, когда  отдел  обработки  данных  сторонней  компании  примет  решение  о  внедрении  ERP  системы.  Например,  Херрера  (Herrera  1999) * То есть быть отдано «на откуп» сторонней  организации  (прим.  науч.  редак-

тора).

114

ЧАСТЬ ТРЕТЬЯ, ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

сообщает,  что  компании  IBM,  принявшей  на  себя  обязательства  по обработке  данных  компании  Kodak,  придется  принять  такое  решение.

Вопросы 1. Каковы достоинства и недостатки использования готовой ERP системы? 2.  Каким  фирмам  подойдет  использование  готовой  ERP  системы? 3. Что приведет к внедрению 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, T. (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  СИСТЕМЫ

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

115

ERP СИСТЕМЫ

Анализ  требований Анализ требований — это обзор системных требований для организационных МОПов.  В  некоторых случаях требования сгруппированы  в  зависимости  от  их  важности,  —  например,  обязательные  или факультативные,  или  расположены  в  определенном  порядке  (скажем)  от  1  до 3.  Требования  отражены  в документе о требованиях (в заявке на предложение — request for proposal,  RPF), который предоставляется  различным  производителям.  Организация  использует этот набор требований для того, чтобы судить о том,  насколько различные части ПО соответствуют ее нуждам.

Сколько требований? Документы с требованиями могут быть довольно большими.  Например,  одна  компания  (фирма А)  с  объемом  продаж,  оценивающимся в 40 млн. долларов, создала документ с 1 000 пунктами требований. Компания Timberjack** с товарооборотом, оценивающимся в более чем 35 млн. долларов,  предъявила 1  042 требования.  Еще более  крупная  частная  компания  (фирма  Б)  в  соответствующем  документе также имела более 1  000 требований.  Количество требований зависит от  размера  фирмы,  определенных промышленных стандартов и от того, кто проводит анализ.

Время на проведение анализа Из-за  большого  числа  требований  и  процессов,  охватываемых ERP системой,  разработка документа с требованиями  может потребовать  значительного  времени  и  средств.  Фирма А  смогла  сделать полный  анализ  всего  за  месяц.  Анализ,  проведенный  компанией Timberjack,  потребовал трех месяцев.  Фирме Б потребовалось четыре месяца на разработку данного документа.

Кто должен разрабатывать (разрабатывает) требования? Кто разрабатывает эти требования? Обычно требования  разрабатываются кем-то, кто хорошо знаком с существующим процессом, и ча-

*  В данной  главе  мы  говорим  о  некоторых фирмах,  не давая  их конкретного названия. Таким  образом,  мы  называем  их фирмами А,  Б,  В (прим.  автора). **  В данном  и последующих параграфах этой  главы мы ссылаемся на компанию  Timberjack,  которая  обсуждается  в  книге  Романова,  Кейла  и  МакФарлена (Romanov,  Keil,  and  McFarlen  1998) (прим,  автора).

116

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

сто тем,  кто выполняет или будет выполнять работу,  входящую в определенный  набор требований.  В  некоторых случаях для создания  моделей существующих процессов привлекаются менеджеры процессов. Вопрос о том,  кто должен  разрабатывать требования, зависит от того,  в  чьем  восприятии  больше  всего  заинтересована фирма.  Если используется текущий персонал, то требования будут отражать существующие процессы. Если ответственность несет менеджмент, требования тоже будут хорошо отражать реальность, так как менеджеры занимаются текущими  операциями.  Менеджеры  могут предъявить требования о том, что, по их мнению, «здесь должно быть» или о том, что «здесь было» тогда, когда менеджер был ежедневно занят в процессе. В  фирмах  А  и  Б  текущие  пользователи,  задействованные  в  том или  ином  процессе,  работали  над  требованиями  вместе  с  консультантом.  В  компании  Timberjack  операции  перемещали  в  другой  город.  В  процессе реализации  проекта консультант работал  с  группой пользователей,  задействованных в текущих процессах,  которые,  как предполагалось, не будут пользоваться новой системой. В Timberjack несомненно испытывали беспокойство о возможной потере знаний о текущих  процессах. При  проведении  анализа  требований  часто  требуются  консультанты — и  из-за их общих знаний об анализе требований,  и  из-за  их стороннего  взгляда  на  процессы.  Возможно,  самая  лучшая  команда —  это та,  которая  совмещает  мнения  менеджеров  и  работников, занятых  в  текущих  процессах,  с  мнением  консультанта,  имеющего опыт и независимую точку зрения.

Рис.  8.1.  Анализатор  потребностей

117

ERP  СИСТЕМЫ

Помощь в проведении анализа требований Кроме  консультантов  существует  ПО,  которое  находит  различные  требования  в  ПО  конкурирующих  производителей.  Например, система  Requirements  Analyst  («Анализатор  потребностей»)  находит различные  возможности  разных  пакетов  бухгалтерского  учета  и  модулей этих пакетов.  Пользователи могут выбрать,  какие возможности им  необходимы,  а затем  произвести  сравнения  своих требований  с возможностями  ПО  поставщика.  Образец экрана  показан  на  рисунке 8.1  (www.ctsguides.com).

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

118

ЧАСТЬ ТРЕТЬЯ.  ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

Недостатки анализа требований У анализа требований  есть  и  некоторые  недостатки.  Во-первых, он  может  отнимать  много  времени,  откладывая  выбор  системы.  В описанных  примерах  потребовалось  от  одного  до  четырех  месяцев на разработку документа с требованиями.  Во-вторых,  анализ требований может быть очень дорогим. Нередко такого рода анализ приводит  к  расходам  на  консалтинг,  оценивающимся  в  100  000  долларов или более,  и это, не учитывая стоимости  времени участников анализа от фирмы,  для  которой  выполняется  этот анализ.  В-третьих,  если документ  с  требованиями  слишком  большой  и  включает  слишком много требований, производители ERP могут не ответить на них из-за своей  занятости.  В  частности,  единственными,  кто  ответит,  могут быть  производители,  располагающие  большим  количеством  времени (т. е.  имеющие большее число незанятых людей).  Если документ с требованиями  слишком  большой,  фирмы  ограничивают  количество компаний,  которые  возможно  ответят  на  них.  В-четвертых,  анализ требований  может  в  конечном  итоге  определить  требования,  которые ограничат фирму устаревшими  методами.  Вместо этого для  нее возможно более выгодным было бы подвергнуть существующие процессы реинжинирингу. В-пятых, процессы (и их взаимодействие) меняются,  так  что  этот  вид  анализа  включает требования,  которые  никогда не стабильны в полной мере. Анализ требований может предоставить  в лучшем  случае «снимок»  процессов  фирмы.

Формат требований Анализ  требований  принимает,  по  крайней  мере,  две  формы. Возможно,  наиболее  часто  используемый  подход  —  это  подготовка подробного списка всего того,  что требуется от ПО.  Этот список посылается поставщикам для того, чтобы они могли сравнить его с возможностями своего ПО. Другой  метод  —  это  «сценарный»  метод,  который  имеет  один или иногда два этапа. Первый этап — этап со свободным сценарием; на  этом  этапе  клиенту  показывают  демонстрационные  версии  ERP

119

ERP  СИСТЕМЫ

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

Анализ несоответствия: сравнение  «как есть»  и  «как должно  быть» Альтернативный  подход — проведение анализа «как есть»  и анализа  «как  должно  быть»  и  их  последующее  сравнение  при  помощи анализа  несоответствия.  Выражение  «как  есть»  относится  к  работе имеющейся системы. Фирма должна впоследствии спланировать направление  перехода  от  модели  «как  есть»  к  модели  «как  должно быть».  Модель  «как  есть»  обеспечивает  сравнительный  анализ  возможностей  имеющейся  системы.  Модель  «как должно  быть»  может быть  результатом  реинжиниринга  «с  чистого  листа»  или  реинжиниринга,  «запускаемого  технологией».  Если  модель  «как должно  быть» разрабатывается  независимо  от  какого-то  определенного  пакета программ,  то  она  является  результатом  реинжиниринга  «с  чистого листа».  Если использован этот метод реинжиниринга, то модель «как должно быть» становится эквивалентной модели требований. Однако все  чаще  анализ  «как должно  быть»  основывается  на  определенном ERP-пакете;  в  этом  случае  он  «запускается  технологией».  Следовательно,  анализ  «как  должно  быть»,  базирующийся  на  готовом  ПО, можно также назвать анализом  «лучших практик». Анализ  несоответствия  используется  для  сравнения  результатов  анализов  «как  есть»  и  «как  должно  быть»  с  целью  определения  того,  какие  несоответствия  существуют  между  тем,  что  компания  имеет  на  данный  момент,  и  тем,  что,  как  она  решила,  ей необходимо.  В  идеале  клиенты  могут  использовать  эту  информацию  при  выборе  ПО,  наиболее  соответствующего  их  нуждам.  Как было  сказано  выше,  выявление  несоответствия  позволяет  фирме определить,  какие  модификации  ПО  могут  потребоваться,  чтобы оно  соответствовало  ее  требованиям.  В  свою  очередь  определе-

но

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

Возникающий подход Консультанты  все  больше  советуют  фирмам  не  делать  анализ «как есть».  Вместо этого внедрение ERP рассматривается  как истинный  реинжиниринг,  «запускаемый технологией»,  который  переходит сразу  к  процессу  «как  должно  быть»,  используя  определенный  ERP пакет. Доводы приводятся следующие: 1) Каждый набор пакетов программ ERP соответствует организационным  нуждам.  Выбранная  ERP система предположительно имеет примерно тот же набор лучших практик, что и любая другая, и все они примерно эквивалентны. 2) Копировать существующие процессы не имеет смысла. Организации не должны копировать существующие (устаревшие) процессы, а должны проводить реинжиниринг,  используя возможности ERP системы. Соответственно, организации должны рассматривать внедрение ERP системы как возможность улучшить существующие у них процессы в свете новых технологий. 3) Априорный анализ лучших практик при внедрении ERP систем не должен иметь места.  Вместо этого анализ лучших практик должен осуществляться только в контексте конкретной части ПО выбранной ERP системы. 4) Так как расходы на внедрение минимизированы путем привнесения  в  ПО лишь  небольшого числа  изменений,  должны  выбираться только лучшие практики, заложенные в ERP системе.

121

ERP  СИСТЕМЫ

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

Проблемы  с анализом требований и  анализом  несоответствия Хотя анализ требований  и анализ несоответствия  имеют множество  преимуществ,  они делают  некоторые  важные  неявные  предположения и игнорируют ряд важных вопросов.

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

122

ЧАСТЬ ТРЕТЬЯ.  ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

Вопросы, игнорируемые обоими методами Анализ требований  и  анализ  несоответствия  обычно  акцентируют  внимание  на  функциональных  возможностях.  В  результате  они обычно игнорируют большое число факторов,  включая следующие. Стоимость.  Анализ  редко  включает  стоимость.  Обычно  анализ указывает  на определенного  поставщика  или  на  нескольких поставщиков и только потом оценивается доступность по цене. Кажется, попытки анализа часто делаются без учета стоимости ПО. Однако отношение  затраты/выгоды  является  одним  из  наиболее  важных фактически  в  любой  бизнес-ситуации.  Игнорирование  затрат  может  являться  следствием того,  кому поручена оценка.  Если оценка  выполняется на нижних уровнях организации, а бюджет контролируется на верхних, то эти два уровня, возможно, будет сложно свести воедино. Время  установки.  В  некоторых  случаях  организации  могут столкнуться с ограниченностью во времени из-за своего желания догнать конкурентов или быть первыми среди внедривших систему. Зачастую такие вопросы, как время установки,  не рассматриваются до тех пор, пока ПО не выбрано. Гибкость.  Понятием  «гибкость»  при  его  использовании  в  отношении ERP систем обычно обозначается способность использования множества лучших практик.  Обычно,  чем  больше лучших практик доступно, тем ПО более гибкое. Пользовательский  интерфейс.  Пользовательский  интерфейс включает и ввод, и вывод данных. Естественно, что фирмы предпочитают более простые в использовании системы. Как мы уже говорили, производители ERP все больше стараются сделать свои системы более легкими в использовании. Способность  к  модернизации.  Существуют,  по  крайней  мере, два  вопроса,  касающиеся  способности  к  модернизации;  как  часто выпускаются новые версии,  и насколько легко провести модернизацию. Слишком частые или слишком редкие замены ПО на новые версии могут создать проблемы. Если модернизация проводится слиш-

123

ERP  СИСТЕМЫ

ком  часто,  фирмы  постоянно  сталкиваются  с  необходимостью  модернизации системы для получения новых возможностей и не знают, сколько же времени будут поддерживаться  их более ранние версии. Если же модернизация проводится слишком редко, фирмы могут не получить тех функциональных возможностей,  которые им нужны. Вычислительная  среда.  Вычислительная  среда  или  философия может быть важным вопросом. Как сообщалось, специализация компании  Oracle  на  вычислительной  среде  «тонкого»  клиента  отрицательно  повлияла  на  мнение  некоторых  экспертов  о  ее  продукте. Вопрос о вычислительной среде может стоять не перед всеми фирмами, но в некоторых ERP система должна будет взаимодействовать с другими системами.  В этом случае интерфейс может стать критически  важным  фактором  выбора,  который  потребует  дополнительной оценки. Персонал  по  внедрению.  Во  многих  проектах  по  внедрению ERP систем важную роль играют консультанты. Таким образом,  квалификация и наличие такого персонала может повлиять на выбор ПО. Поэтому некоторые фирмы  включают персонал по  внедрению в анализ в качестве важной переменной. Текущее  использование  и  обслуживание.  После  внедрения ERP  системы  происходит  переход  к  ежедневному  использованию  и обслуживанию.  Обслуживание  конкретных  ERP  систем  может  быть различным. Таким образом, этот набор факторов также необходимо включить в анализ.  К сожалению, группа по выбору ERP системы может быть иной, чем группа внедрения, которая в свою очередь может быть иной,  чем  группа обслуживания.  Следовательно,  важность этого фактора интерпретируется по-разному. Функциональные  характеристики.  Как  будет  рассказано  в следующем  параграфе,  некоторые фирмы  могут попытаться  оценивать  функциональность  в  качестве  единственного  фактора.  В  этом случае может возникнуть непонимание того, что составляет «функциональность», и это понятие будет варьироваться в зависимости от того, кто его употребляет.

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

124

ЧАСТЬ ТРЕТЬЯ, ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

ветствия фокусируются только на функциях, а существует и множество других вопросов, то встает вопрос, как же организации оценивают и  выбирают  ПО?  В данном  параграфе  описывается  подход,  использованный  компанией  Timberjack  (Romanow  и  др.  1998);  пример  использования другого метода дается в приложении.

Timberjack Компания  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 системе. Однако, насколько разумно оценивать в числах такие аспекты,  как «виды  на будущее»  и другие фак-

125

ERP СИСТЕМЫ

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

Манипулирование факторами и их весами К сожалению, выбранными факторами и соответствующими весами можно манипулировать. При наличии информации о двух или более ERP системах факторами и их весами можно манипулировать в пользу определенного пакета программ в ущерб другим. Например, компания Timberjack установила для функциональных возможностей вес,  равный только 30 (из 160). Такой низкий вес говорит не в пользу систем с широкими функциональными возможностями, а именно на эти возможности делается  основной  акцент  при  осуществлении  анализа  требований  и анализа несоответствия. Это показывает то, как факторами, используемыми в процессе оценки, можно манипулировать в пользу выбора определенной системы. Более того, факторов может быть слишком много  или,  наоборот,  набор  факторов  может  быть  неполным.  Например, компания Timberjack выбрала восемь факторов, среди которых не было таких, как, например, «персонал по внедрению» или «обслуживание».

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

Выбор против объяснения Факторы  и их веса — это инструмент либо для выбора ПО, либо для  его  объяснения,  отчасти  в зависимости  от того,  когда  выбраны факторы и назначен вес.  Если факторы и их веса выбраны до оценки ПО, они обеспечат базис для выбора, основанного на априорном понимании ПО и организации.  Если факторы и их веса выбраны после оценки  ПО,  они  могут дать толкование выбору с рациональной точки зрения.

Кто должен выбирать факторы и их веса? Часто  к  проекту  выбора  привлекаются  консультант  или  группа  консультантов.  Роль  консультанта  может  заключаться  в  обес-

126

ЧАСТЬ ТРЕТЬЯ.  ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

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

Факторы стоимости На  уровне  бюджета  фактор  стоимости  ПО  является  самым важным.  В  некоторых  же  случаях,  как  отмечалось  ранее,  стоимость  игнорируют.  Как  фирмы  принимают  в  расчет  стоимость  в процессе  выбора?  Одним  из  методов  (использованным  фирмой  Б) было  перечисление  трех  видов  стоимости  и  использование  при выборе  их  суммы  (см.  таблицу  8.2).  (Фирма  Б,  в  конечном  итоге, выбрала  SAP). Таблица  8 . 2 .  Стоимость  ERP* Существующая система Внедрение Специальная настройка ПО Количество обслуживающего персонала

Oracle

3-5 2-4

4-8 1-3

15-20

10-15

SAP

6-10 минимальна 8-10

* Все цифры — в млн. долларов.

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

127

ERP  СИСТЕМЫ

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

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

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

128

ЧАСТЬ ТРЕТЬЯ.  ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

Литература Romanow,  D.,  Keil,  M., 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. Гэри Чеймис, вице-президент и СЮ компании, установил процесс выбора корпоративного ПО, состоящий из пяти шагов: •  сформировать  небольшую,  тщательно  подобранную  команду; •  связаться с поставщиками для организации демонстрации ПО; •  попросить поставщика доказать его способность быстро  внедрить систему; •  проголосовать; •  осуществить  выбор.

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

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

Попросить поставщика доказать его способность быстро внедрить систему. Так как быстрое внедрение было одним  из тре*  Данное  приложение  основано  на  статье  G.  Cheimis  (1999),  «Shooting  the Rapids of a  Rapid  Implementation,»  опубликованной  в  Shape Your World,  Focus  '99 (Denver,  CO:  J.D.  Edwards)  (прим.  автора).

129

ERP СИСТЕМЫ

бований  компании  Chesapeake  Display  &  Packaging  (CDP),  на демонстрации  поставщиков попросили доказать их способности  к внедрению.  При этом  были  предъявлены следующие требования: Таблица 8.3.  Результаты голосования  при  выборе  ПО в  компании  Chesapeake Соответствие функциональности Подразделение*

Гэри Чеймис Элвис Брэннам

CDP CDP

Линда Виттер Тед Сэмойтс

CDP CDP

Джек Керк Джон Полгар Карл Уилкокс

CDP CDP CDP

Ричард Гастингс

CDP

Мери Джин Симмионс

СС

Дик Фасе Ренди Грам Билл Толи Дэвид Спенсер

СС СС СС СРС

Анна Уолш

СРС

Персонал по внедрению

Должность

BAAN

JDE

вице-президент, СЮ менеджер по информационным системам поддержка продаж менеджер по производству вице-президент, CFO старший аналитик администратор по разработке менеджер по операциям

3

2

1

2

3

1

2 3

3 2

1 1

3 3

2 2

1 1

2 2 2

3 3 3

1 1 1

2 2 2

3 3 3

1 1 1

3

2

1

3

2

1

3

2

1

3

2

1

2 3

1 1

2 2

1 1

2

3 3 3 3

2

2

директор по управлению акциями аналитик внутренний аудитор CFO технический менеджер менеджер по информационным системам

1

SSA BAAN JDE SSA

2

1

1

2

3 3 3 3

3

1

2

3

1

3

1

2

3

1

2 1

* CDP — Chesapeake Display & Packaging; CPC — Chesapeake Packaging Corporation; CC — Chesapeake Corporation.

•  показать,  что ПО сможет работать с нашим бизнесом; •  показать,  что  вы  сможете  внедрить  его  в  течение  требуемого времени; •  показать свое  понимание отрасли. Проголосовать.  После демонстрации  были  выбраны  три  основные кандидата:  BAAN, J.D.  Edwards (JDE) и SSA.  Чтобы выбрать одного из них, команду выбора попросили проголосовать, основываясь на двух моментах:  наиболее  подходящие  функциональные  возможности и лучший персонал по внедрению.  Чтобы голосование было простым,

130

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

голосующих попросили оценить каждую из опций ПО в диапазоне от 3 до  1  баллов, где 3 — высший балл.  Каждого члена команды попросили  дать  оценку,  базируясь  на  своей  сфере  ответственности.  Результаты голосования  отражены  в таблице 8.3. Рекомендованное ПО.  Из трех систем управления  предприятием была выбрана система J.D.  Edwards, так как в сумме она получила наибольшее  количество  баллов.  Чеймис  обозначил  следующие  характеристики, обеспечиваемые J.D. Edwards: •  наилучшие финансовые характеристики; •  единое интегрированное решение; •  наличие  модулей  управления  персоналом  и  расчета  заработной платы; •  продвинутый  объектно-ориентированный  набор  инструментов; •  соответствующий  потребностям  продвинутый  модуль  планирования, позволяющий планировать на основе стоимости.

Вопросы 1.  Как  вы  думаете,  какую  ERP  систему  выберет  компания  Chesapeake? Почему? 2. Каковы сильные и (возможно) слабые стороны метода выбора ПО, использованного компанией Chesapeake?

Приложение  8-2 Исследование, проведенное одним финансовым директором Мы находимся на стадии оценки различных ERP систем. У нас есть краткий список различных поставщиков ПО,  и,  в конечном  итоге,  мы решили получше взглянуть на SAP. Вместе с консультантом (Coopers & Lybrand) мы разработали проект, состоящий из трех этапов: 1) анализ «как есть»; 2) анализ  «как должно  быть»; 3) процесс приведения в соответствие (соответствие двух видов анализа). Мы пришли к выводу, что SAP не удовлетворяет нашим требованиям.  В частности,  модуль производства был далек от наших ожиданий и не дал нам той информации, которую мы сейчас имеем. Существует множество несоответствий между анализами «как есть» и «как

131

ERP  СИСТЕМЫ

должно быть».  Кроме того,  SAP  (из-за ее  интегрированности)  не  настолько гибкая система, как та, которую мы используем сейчас. В  системе,  используемой  нами  в  данный  момент,  в  реальном времени доступен огромный объем информации. Кроме того, эта система была создана нашими работниками и является «ориентированной  на потребителя».  Возможности этой системы по  использованию информации в реальном времени просто потрясающая, и это является  ключевым  фактором  в  наших отношениях с  клиентами.  К сожалению,  модуль  производства  системы  SAP  не  может  идти  ни  в  какое сравнение. Так  как  есть  несколько  несоответствий,  придется  много  программировать, если мы хотим получить то, что имеем в системе,  используемой  нами  в  данный  момент.  В  результате  мы  попросили Coopers  &  Lybrand  предоставить  нам  подробный  отчет  о  стоимости проекта.  Если  нам  придется  покупать  SAP  только  из-за  финансовых модулей и модулей закупок, то система слишком дорогая. У меня  возникли следующие вопросы: •  Стоит ли  покупать интегрированную систему,  в которой все же потребуется  много программировать? •  Не может ли проект стать слишком дорогим? Решение,  которое  мы  собираемся  принять  в  скором  времени, конечно,  сложное.  Есть  ли  какие-нибудь  варианты?  Буду  рад  получить советы.

ПРОЕКТИРОВАНИЕ  ERP  СИСТЕМ Что нужно менять — бизнес-процессы или программное обеспечение ERP систем? Выбирая  ERP  систему,  фирмы  сталкиваются  с  необходимостью принять решение о  проекте с точки зрения  «политики  реинжиниринга»,  степени  переделки  ПО  под нужды  предприятия  и  необходимого организационного реинжиниринга. С одной стороны, так как ни одно ПО не отвечает всем потребностям фирмы, некоторые фирмы приняли решение о значительной его переделке под свои процессы. С другой  стороны,  многие  организации  использовали  внедрение  нового ПО как шанс для  изменения своих основных бизнес-процессов,  проводя  реинжиниринг в своей организации для  приведения  процессов в  соответствие  «лучшим  практикам»,  содержащимся  в  ERP  системе.

132

ЧАСТЬ  ТРЕТЬЯ.  ЖИЗНЕННЫЙ  ЦИКЛ  ERP  СИСТЕМ

Для  выяснения  степени,  в  которой  различные  фирмы  следуют  различным  подходам,  исследовательская  компания  Forrester  Research провела исследование (Lamonica  1998),  выявившее следующие процентные показатели; •  выбор  приложений,  соответствующих  бизнесу,  с  небольшой переделкой — 37%; •  переделка  приложений  для  приведения  их  в  соответствие  с бизнесом — 5%; •  проведение  бизнес-реинжиниринга  для  соответствия  приложению — 4 1 % ; •  отсутствие определенной политики —  17%. В данной главе анализируются два основных вопроса. 1) Как политика реинжиниринга влияет на процесс выбора ПО? 2) Что нужно менять — бизнес-процессы или ПО ERP систем?

Как политика реинжиниринга влияет на процесс выбора ПО: к вопросу о важности моделирования «как есть» и  «как должно  быть» Решение о модификации ПО или о реинжиниринге бизнес-процессов (или того и другого) влияет на важность и использование моделирования «как есть» и «как должно быть».  В результате решение о реинжиниринге  нужно  принимать  вместе  с  решением  о  выборе  ERP системы. Так как анализ «как есть» порождает модели существующих процессов, значимость такого анализа зависит от степени неизменности процессов. Так как анализ «как должно быть» порождает моде-

Минимальная 

Высокая

Запланированная степень изменения организационных процессов

Рис.  9.1.  Когда  необходим  анализ  «как  есть»?

133

ERP  СИСТЕМЫ

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

К вопросу о важности для ERP систем модели «как есть» Фирмам,  планирующим  сохранить  существующие  процессы  (и проводящим реинжиниринг в небольшом объеме или не проводящим его вообще),  полезно проводить обширный анализ «как есть»,  чтобы убедиться, что ПО соответствует их нуждам. В такого рода ситуациях, чем лучше ПО подходит существующим процессам, тем лучше. Однако  если  фирма  планирует  обширный  реинжиниринг  процессов  (как 40%  фирм  в  исследовании  организации  Forrester  Research),  то  модель «как есть» несколько теряет свою важность. Так как многие фирмы, внедряющие ERP, планируют реинжиниринг своих процессов, нет большой  необходимости  разрабатывать  классическую  модель  «как есть». Таким образом, фирмы все больше отказываются от проведения это вида анализа. См. рис. 9.1. У  использования  модели  «как  есть»  существуют  потенциальные проблемы. Рассмотрим фирму, которая проводит анализ «как есть» и обнаруживает  плохое  соответствие  существующих  процессов  ERP системе,  которую  она  выбирает.  Если  запланирован  минимальный реинжиниринг, то организация, возможно, упустила возможность выбора ПО, которое подходит ее процессам. Рассмотрим фирму, которая проводит анализ «как есть» и планирует обширный реинжиниринг этих существующих процессов. Выбор ERP системы, которая хорошо

Минимальная 

Высокая

Запланированная степень изменения организационных процессов

Рис.  9.2.  Потенциальные  проблемы,  использования модели  «как  есть»

134

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ ERP СИСТЕМ

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

К вопросу о важности моделей «как должно быть» Если запланирована ограниченная  модификация  ПО,  выбор процессов  «как должно  быть»  обычно  ограничивается теми  процессами, которые доступны  в ERP системе.  В таком случае анализ «как должно быть» — это  проблема выбора из набора процессов,  доступных в ERP системе. Однако  если  ПО  должно  быть  значительно  модифицировано, анализ  «как  должно  быть»  не  является  более  проблемой  выбора  из набора  процессов,  а  является  проблемой  разработки  процессов. Анализ  «как  должно  быть»  становится  больше  похож  на  реинжиниринг «с чистого листа» (а не на реинжиниринг, «запускаемый технологией»),  ограниченный только  зависимостью  от процессов,  заложенных в ERP системе.  Эта динамика показана на рис.  9.3.

Организационные изменения и изменения в ПО: реинжиниринг  против  Реинжиниринга Наш  анализ  значимости  моделей  «как есть»  и  «как должно  быть» принял  два  направления:  степень  изменения  организационных  процессов  и  степень  изменения  ПО.  Эти  две  переменные,  определяющие степень необходимого  реинжиниринга,  являются  основой дальнейшего сравнительного исследования. Эйдан  Вейн,  который  был  менеджером  проекта  от  SAP  при внедрении  корпорацией  Microsoft  системы  SAP  R/3  под  управлением  операционной  системы  Windows  NT,  назвал  это  внедрение «реинжинирингом  с  маленькой  буквы  с  системой  SAP  R/3  в  качестве  агента  изменений».  Microsoft  внедрила  финансовые  модули SAP,  используя  процессы,  доступные  в  SAP  R/3,  без  модификации  ПО.  Кроме  того,  так  как  Microsoft  внедрила  только  финансовые  модули,  соответствие  ее  процессов  возможностям  системы  было  действительно  хорошим.  Если  Microsoft  провела  реинжиниринг  «с  маленькой  буквы»,  то  что  же  такое  Реинжиниринг («с  большой  буквы»)?

135

ERP  СИСТЕМЫ

Минимальная  Высокая Запланированная  степень изменения организационных процессов Рис.  9.3.  Какая  разновидность  анализа  «как  должно  быть» необходима?

Реинжиниринг «с большой буквы» был бы всесторонней модификацией  организационных процессов  и  ERP системы.  При  реинжиниринге «с маленькой буквы»  организация  внедряет ПО,  которое хорошо  соответствует ей;  однако  при  реинжиниринге  «с большой  буквы» она меняет под свои нужды и процессы, и ПО. Эти два подхода изображены на рис. 9.4. В  следующих четырех  параграфах  рассматривается  каждый  квадрант изображенной на этом рисунке модели с описанием примеров, достоинств и недостатков,  а также характеристик фирм,  которые являются  вероятными  кандидатами  на их внедрение.

Минимальная  Высокая Степень изменения ПО Рис.  9.4.  Реинжиниринг  «с  маленькой  буквы»  и  «с  большой  буквы»

136

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

Пример Классический  пример  реинжиниринга  «с  маленькой  буквы»  — случай  Microsoft.  Корпорация  внедрила систему SAP R/3,  внеся  в ПО минимальные  изменения.  ПО  предоставило  лучшие  практики,  приемлемые для  Microsoft.  В  некоторых случаях  принятие  лучших  практик,  используемых  в  ПО,  подразумевало  изменения  в  организации. Однако  в  целом,  очевидно,  в  бизнес-процессы  и  организацию было внесено совсем немного изменений.

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

137

ERP  СИСТЕМЫ

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

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

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

138

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ ERP СИСТЕМ

причине) не имеют терпения, ресурсов или заинтересованности в изменении  ни  своей  организации,  ни  ПО.  Например,  в  случае  с Microsoft  были  разработаны два  предыдущих  проекта  внедрения  ERP систем  модели  клиент-сервер.  На  эти  проекты  были  потрачены значительные  ресурсы  и  время.

Интересы и отношения производителей ERP в данной области Производители  систем  планирования  ресурсов  предприятий, такие  как  SAP,  недвусмысленно  выражают  интерес  к  фирмам,  внедряющим  средства  реинжиниринга  «с  маленькой  буквы».  Малым  и средним  предприятиям  SAP обычно  рекомендует не вносить  изменения  в  ПО.  Например,  компания  SAP  разработала  методику ASAP,  чтобы  такие фирмы  внедряли  ее системы.

Значительные  организационные  изменения и минимальные изменения  в ПО Некоторые  полагают,  что  одной  из самых важных точек зрения  на ERP  системы  является  та,  согласно  которой  ПО  дает  возможность  и способствует  изменению  бизнеса.  Например,  как  заметил  Кевин Маккей,  президент  компании SAP America: Пользователям  SAP  R/3  часто  приходится  менять  свой  бизнес для использования ПО, но стоимость и изменения стоят того, так как ПО  позволяет компании  работать более эффективно  ...  Это  не  проект  внедрения  [информационной  технологии],  а  трансформация бизнеса.  (Bailey 1999) Хотя  ERP  предоставляет  организациям  «благоприятную  возможность»  изменить  бизнес,  некоторые  фирмы  из данного  квадранта  не видят необходимости  менять процессы.  Напротив,  они рассматривают ее как принуждение при внедрении и ограничения  ПО.  Если бы  ПО было  разработано  более  полным  и  включало  бы  большее  количество процессов,  то  многие  изменения  организационных  процессов  были бы  не  сильно  необходимы.

Примеры Wall  Street  Journal  (Bailey  1999)  недавно  написал  о  ситуации, сложившейся  с  группой  фирм,  занимающихся  вывозом  отходов,  ко-

139

ERP  СИСТЕМЫ

торые  посчитали  свое  ПО  SAP  «ПО  для  свалки».  Две  лидирующие  в данной  области  фирмы  (Allied Waste  и Waste  Management)  осуществляли  внедрение  SAP,  но  прекратили  этот  проект.  Одну  из  основных причин  указал  Томас  Ван  Вилден,  СЕО  компании  Allied  Waste:  «Они [SAP] ждут,  что  вы  измените свой бизнес для того,  чтобы  работать с их программным  обеспечением». В  этом  квадранте  проекты  внедрения  не  всегда  заканчиваются тем,  что фирмы  «выбрасывают на свалку»  ПО SAP.  Например,  как заметил  Девид  Эдмондсон,  помощник  проректора  по  информационным услугам Техасского христианского университета: «Мы переделали программное обеспечение совсем немного. Наш специалист-системотехник помогает нам  менять наши бизнес-процессы. Лучше изменить  их,  чем  модифицировать  программное  обеспечение» (Lamonica 1998).

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

140

ЧАСТЬ ТРЕТЬЯ,  ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

Возможные и невероятные кандидаты на внедрение Фирмы,  внедряющие  ERR  расположенные  в  данном  квадранте,  — это фирмы,  которым легче изменить людей,  чем  ПО,  или,  по крайней  мере,  для  них это  более  рентабельно.  Консультант компании  PricewaterhouseCoopers,  специализирующийся  на  ERP  системах,  отметил:  «Легче изменить людей,  чем программное обеспечение  ...  Изменение  менеджмента становится  важным  средством успешного  изменения  процессов». Изменение бизнес-процессов  может быть сложным  в некоторых ситуациях.  Например,  если  фирма  сильно  децентрализована  (как  в случае  с  фирмами,  занятыми  вывозом  отходов),  то  изменение  процессов  может  стать  проблематичным,  так  как  при  наличии  разных требований сложно выбрать (и  внедрить)  общие процессы  в  различных  условиях.

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

Примеры Проектный  менеджер  компании  Nestle  заметил,  что  выбранные компанией процессы при внедрении SAP включали лучшие практики, не входившие в данное ПО.  В частности, были выбраны некоторые из процессов и лучших практик, существующих в БД консультантов компании,  что стимулировало изменения в ПО. Приведем  другой  пример.  Менеджер  по  обслуживанию  SAP  в Deere  Company  заметил:  «Мы  серьезно  переделали  программное обеспечение, так как у нас есть в этом большой опыт,  и мы это делаем  хорошо.  Это  сработало  и  удовлетворило  потребности  компании» (Lamonica  1998).

Достоинства и недостатки Изменение  ПО  имеет  ряд  отрицательных  сторон.  Изменения делают  сложными  обслуживание  и  модернизацию  ПО.  Как  сказал  Стив  Купер,  директор  корпоративных  систем  компании Corning:

141

ERP СИСТЕМЫ

Мы  поняли  трудность:  если  модифицировать  программное обеспечение,  возникнут затраты.  Затраты на начальную модификацию, на модернизацию и на поддержку программного обеспечения. (Lamonica1998) Переделка  ПО  под требования  различных  подразделений  также может  создать  трудности  его  внедрения  в  других  подразделениях. Хотя  менеджер  по обслуживанию SAP  в компании  Deere Company заметил, что переделка ПО в рамках проекта внедрения ERP прошла успешно,  было также сказано:  «То,  что не работало, хорошо устанавливает стандарты  и  образцы,  которые  могут быть  предъявлены другим подразделениям»  (Lamonica  1998).

Вероятные кандидаты на внедрение Процессы,  создающие  ценность,  которые  варьируются  от  компании  к компании,  являются  потенциальным  источником  изменений ПО. Например, будут, вероятно, изменены модули управления производством или созданы соединения с традиционными системами. Размер компании имеет большое влияние на ее способность измениться или изменить ПО.  Более крупные компании имеют большие ресурсы, так что они могут легко изменить ПО. Как сказал СЮ компании  Penwest  Pharmaceuticals:  «Большие  компании  мало  подвижны, чтобы  измениться  для  соответствия  программному  обеспечению» (Lamonica  1998).

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

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

142

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ 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:

143

ERP СИСТЕМЫ

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

Интересы и отношения производителей ERP в данной области Продажа компанией BAAN ERP системы компании Boeing сделала  BAAN  одним  из главных участников  ERP-бизнеса.  Поскольку  BAAN добавила новые лучшие практики и изменила ПО так, как это было необходимо  крупному  производителю  —  подрядчику  правительства, другие похожие фирмы (например,  Litton Data Systems) тоже приобрели ПО BAAN. С другой стороны,  чем больше ERP система соответствует нуждам  определенной фирмы,  тем  меньше возможность,  что она будет соответствовать нуждам других компаний. Таким образом, внесение значительных изменений в  ПО или конкретные лучшие практики может фактически ограничить продажи ERP систем другим фирмам. Некоторые  даже  утверждают,  что  в  результате  обслуживания  фирмой BAAN компании Boeing она получила и систему, и имидж, не привлекательные для фирм, не имеющих отношения к данной отрасли.

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

144

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  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  (прим,  автора).

145

ERP  СИСТЕМЫ

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

Провал  внедрения  и  факторы  успеха Успешное  внедрение  ERP  системы  чаще  всего  возможно  в  тех случаях, когда существует лишь минимальная потребность в изменении  бизнес-процессов  и  ПО.  Это  не  значит,  что  все  организации должны вносить в ПО лишь минимальные изменения, а только то, что существует большая возможность, что такое внедрение будет успешным. Если  большинство  изменений  касается  организационных  процессов  (значительные изменения  в процессах организации  и  минимальные изменения в  ПО), то организационные недостатки  внедрения,  выбор  не  тех  лучших  практик  или  сопротивление  изменениям (среди других факторов) могут привести к неудаче. С другой стороны, если большинство изменений касается ПО (минимальные изменения в процессах организации и значительные изменения в ПО), то одним  из  факторов  неудачи  является  неспособность  организации осуществлять большие  ИТ-проекты.  Наконец,  если  осуществляются большие изменения и в организационных процессах, и в ПО, то или/и те,  или/и другие  проблемы  могут  повлиять  на  возможность успеха. См. рис. 9.5.

Минимальная 

Высокая

Степень изменения ПО

Рис.  9.5

146

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

Какой  квадрант?  Какой  метод? Какой  метод  —  от  реинжиниринга  «с  маленькой  буквы»  до реинжиниринга  «с  большой  буквы»  —  работает  лучше,  зависит  от фирм,  осуществляющих  внедрение,  их  возможностей  и  ограничений  и  компромиссов,  которых  они  хотят  достичь.  Фирма  может выбрать  реинжиниринг  «с  маленькой  буквы»  и  успешно  внедрить ПО,  упуская,  однако,  возможность  реинжиниринга  бизнес-процессов.  С  другой  стороны,  фирма  может  выбрать  реинжиниринг «с  большой  буквы»,  неся  большие  расходы  и  тратя  много  времени  на  внедрение,  но  зато  станет  первой  в  отрасли,  кто  установил  ERP  систему,  и  будет  пользоваться  соответствующими  преимуществами.  На  протяжении  всего  времени  возникает  балансирование  между  расходами  и  результатами,  зависящее  от  использованных  критериев  (а)  выбора  ERP  системы  и  (б)  общей  оценки завершенности  проекта.

Резюме В  данной  главе  представлен  анализ  вопроса:  «Что  нужно  менять  —  бизнес-процессы  или  ПО  ERP  систем?»  В  процессе  анализа  мы  исследовали  важность  двух  видов  моделирования:  «как есть»  и  «как  должно  быть»,  и  выяснили,  например,  что  во  многих случаях  анализ  «как  есть»  не  нужен.  Кроме  того,  в  данной  главе представлены  понятия  реинжиниринга  «с  маленькой  буквы»  и  «с большой  буквы».  Мы  исследовали  те  условия,  в  которых  главным является  изменение  ПО,  изменение  организационных  процессов,

147

ERP  СИСТЕМЫ

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

Литература Bailey,  J.  (1999).  «Trash  Haulers  Are  Taking  Fancy  Software  to  the  Dump».  Wall Street Journal, June 9. Busse, T.  (1998).  «Boeing Takes Off with BAAN».  InfoWorld, July 6. Crow,  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,  С  (1998).  «Big  Retail  SAP  Project  Put  on  Ice».  Computerworld, November 2, pp. 1, 104.

Приложение  9-1* Внедрение системы SAP корпорацией Microsoft Клиенты  и  разработчики  продукции  Microsoft  пользуются большей частью технологических ресурсов корпорации. Таким образом, администрация компании и ее внутренний менеджмент, включая финансовую группу, зачастую не получали необходимых им ИТ-ресурсов.  Как сказал Скотт М.  Боге,  помощник корпоративного управляющего:  «Что меня больше всего поразило,  когда я пришел сюда,... так это то, что в области финансов Microsoft была не только не передовой компанией, а напоминала страну третьего мира» (Wallace 1995).

Данное  приложение  базируется  на  материале  «Microsoft  Corporation», представленном  в  Bashein,  B.,Markus,  L,  and  Finley,  J.  (1997).  Safety  Nets:  Secrets of  Effective  Information  Technology  Controls.  (Morristown,  NJ:  Financial  Executives Research  Foundation).  Многие  цитаты  были  взяты  из этого  источника.  Материал, представленный здесь, был специально отобран, организован и переписан.

148

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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.  He  стало  сюрпризом,  что  в  связи  со  своей  высокой  квалификацией  и  простотой пользования  ПО  служащие  Microsoft  нетерпеливы  в  отношении  обучения  использованию  ПО.

Финансовая  группа и  финансовые  системы  корпорации  Microsoft Основной бизнес компании Microsoft — технологические инновации. Значит, решения принимаются, исходя из технологических и рыночных  соображений,  а  не  из  сложных  расчетов  капиталовложений. Как заметил Боггс:

149

ERP СИСТЕМЫ

Главный риск для Microsoft — потерять возможности для инвестиций в новые технологии.  В результате мы — не та компания, где главной движущей силой  являются финансы.  Мы  не тратим много времени на проведение анализа движения денежной наличности перед приобретением ... Две движущие силы нашего бизнеса — это доход и фиксированные расходы (по большей части на людей). Эти  требования  повлияли  на  роль  и  возможности  финансовой группы. Финансовая группа говорит, что результаты ее деятельности  — это  «значимая,  своевременная,  качественная  финансовая  информация»  и  «соответствующие,  поддерживающие,  профессиональные услуги».  Обязанности  и  умения  финансовых специалистов компании  Microsoft в области ИТ трудно отличить от их группы поддержки ИТ (information technology group,  ITG).  К. Д. Холман, директор группы информационных технологий, заметил; Здесь все увлечены технологией.  Например, некоторые из наших финансовых специалистов получили два образования (финансы и администрирование информационных систем или компьютерные науки). Обязанности в области финансов и ИТ постоянно переопределяются. На сегодняшний день они очень нечеткие.

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

150

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

полнительных дорогостоящих изменений других систем.  Обслуживание интерфейсов было примерно эквивалентным обслуживанию приложений  и  БД.  Эйдан  Вейн,  руководитель  проекта  NT  SAP,  сделал следующий комментарий: По  нашим  подсчетам,  ITG  обслуживает  более  400  приложений.  А  это  большие  системы.  Чтобы  вы  поняли,  насколько  большие,  скажу,  что  мы  считаем  MAC  РАС  [большой  программный комплекс  материального  планирования]  единым  приложением. По  крайней  мере,  половину  этих  приложений  может,  в  конечном итоге,  заменить  SAP. Некоторые  из  пакетов  программ,  которые  компания  Microsoft приобрела, были настолько  модифицированы,  что  их производители больше их не обслуживали.  Кроме того, не были доступны некоторые важные  финансовые  возможности,  и  финансовые  системы  не  удовлетворяли потребностей  в своевременной финансовой информации. Более того,  имевшиеся системы  не смогли бы  поддерживать проекты  роста  в  будущем.  Первое закрытие  (бухгалтерских  книг)  в  конце года заняло три недели, а каждое последующее закрытие в конце месяца  занимало  две  недели.  Компании  необходимо  было  повысить скорость доступа менеджеров к информации.

Проблемы с процессами и объектами Кроме проблем с традиционными системами у Microsoft существовали  некоторые  ограничения  и  проблемы  с  основными  финансовыми  процессами  —  в  особенности,  с  закупками.  Как  объясняет Скотт  Боге:  «Мы  были  недостаточно  практичными.  Например,  в  закупках.  Мы сидим на огромной куче денег и поэтому никогда не вели серьезных переговоров о скидках».  Microsoft имеет очень свободную политику закупок,  и  почти  все служащие совершают закупки  на сумму до  1  000  долларов  без  предварительного  одобрения  (предварительное  одобрение требовалось для  покупок  на  сумму свыше  1  000 долларов и на юридически оформляемые контракты). В дополнение к такой  свободной  политике  существовало  не  очень строгое  следование  процессам  закупок.  Как сказал  Грег Хармон,  руководитель проекта  SAP:  «В  некоторых  случаях  мы  только  тогда  узнавали  о  наших [финансовых и  юридических]  обязательствах,  когда  получали  счета». Проблемы были  не только с процессом закупок. •  Как  сказал  Хармон,  компании  Microsoft  необходимо  было  повысить скорость  выплат поставщикам.

151

ERP  СИСТЕМЫ

•  Кроме того,  по  словам  Вейна,  «в  области  основных  средств... Microsoft требуется от 75 до 90 дней на то,  чтобы  внести актив в  бухгалтерские  книги  [например,  компьютерное  оборудование],  когда он уже стоит на чьем-нибудь столе». Также были  проблемы  с  объектами  системы,  такими  как списки поставщиков.  Например, подконтрольные компании не имели общей схемы расчетов или списков поставщиков.

Решение  о  замене  внутренних  систем В  1992  г.  Microsoft  начала  рассматривать  в  качестве  своих  внутренних  систем  управления  решения,  работающие  в  среде  клиентсервер.  ITG  несла  ответственность за  внутренний  менеджмент  и  административные системы компании. Она была централизованной и в то же время организованной в подгруппы по разработке приложений для  различных  групп  внутренних потребителей. ITG  проводила  политику  использования,  по  возможности,  готового ПО. Члены группы оценили три различные финансовые системы, работающие  в  среде  клиент-сервер:  Dun  and  Bradstreet  (D&B), Platinum  и  SAP.  Было  выбрано  ПО  D&B,  находившееся  в то  время  на стадии  разработки.  Microsoft начала установку программного пакета в  рамках  бэта-тестирования*.  Через  18  месяцев  внедрение  было приостановлено, так как ПО было недостаточно  развитым,  и отсутствовала бизнес-поддержка. Между тем, компания SAP America стала лидирующим производителем  ERP  систем  для  работы  в  среде  клиент-сервер  в  Соединенных Штатах.  Система SAP R/3  все еще не имела всех функциональных возможностей  системы  R/2,  базирующейся  на мейнфрейме.  Однако  SAP была лидером рынка, и это означало то, что она, возможно, будет иметь стимулы и ресурсы для расширения своей деятельности в будущем. В  1993 г.  ITG обнародовала  план  внедрения  полного  пакета программ SAP, охватывающего всю компанию.  Было запланировано внедрение  финансового,  операционного  модулей  и  модуля  управления персоналом.  Этот  проект  продолжался  около  двух  лет,  пока  Билл Гейтс не поставил вопрос о его бизнес-целях и его пользе. По окончании проекта ITG была реорганизована. После реорганизации  разработчики  приложений  были  распределены  между  своими

1

  Эксплуатационные  испытания  с  целью  поиска  ошибок  в  ПО (прим,  автора).

152

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ ERP СИСТЕМ

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

Выбор SAP Решение  исполнительных  органов  об  установке  SAP  R/3  состоялось  в  1994  г.  Стив  Баллмер  (вице-президент  по  продажам  и  поддержке)  посетил  компанию  Wal-Mart,  которая  прислала  ему  персональное  приглашение.  Wal-Mart была  широко  известна своими  сложными  информационными  системами,  и  Баллмер  был  впечатлен  ее достижениями. Коннорс  описал,  какую  реакцию  вызвали  у  Баплмера  системы Wal-Mart,  и его указания финансовой  группе  Microsoft: У нас был очень плохой процесс бюджетирования.  ITG и финансовое  подразделение  разработали  новую  программу для  бюджетирования,  но  она  не  работала...  Дело  было  серьезно...  Я  только  что вернулся из отпуска, а Стив Баллмер только что приехал из Wai-Mart. Стив постучался и открыл дверь моего кабинета. Я уже знал, что это был  Стив,  он  всегда  стучался  по-особенному.  Он  вошел  и  сказал: «Вы  издеваетесь  [ненормативная  лексика  опущена]!»  Я  его  понял. (Bashein,  Markus, and Finley 1997) Помощник корпоративного  управляющего  Скотт  М.  Боггс,  руководивший  бизнес-частью  проекта,  отметил:  «Мы  не  оправдали  проект  с  финансовой  точки  зрения.  Он  важен  со  стратегической  точки зрения  и  поддерживался топ-менеджментом».

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

153

ERP СИСТЕМЫ

ление финансовых ИТ выбрали финансовые модули системы 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,  что  они  должны быть частью  команды.  Я  поступил  правильно,  назначив  руководить бизнес-частью проекта человека из финансового отдела. В прошлом дело обстояло иначе.  Во-вторых, это означает сказать:  «Это то, что делаем мы... Нам не могут указывать, делать это или нет и как это делать». Я объездил с кратковременными визитами весь мир, чтобы донести это до всех. В-третьих, это означает получать поддержку от ру-

154

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ ERP СИСТЕМ

ководства — делать так,  чтобы  Баллмер  или  Билл уничтожали любое возникающее  препятствие.  В-четвертых,  это  означает  говорить всем, как это важно для Microsoft, и работать слаженно, одной командой  с отделами  маркетинга  и  продаж.  В-пятых,  это  означает нанять очень хорошего проектного менеджера. Коннорс  назначил  ответственным  за  весь  проект  Скотта  Боггса. Боггс не занимался  ИТ,  но  он  был  важной  фигурой  в  бизнес-процессах,  напрямую  связанных  с  проектом,  он  был  «владельцем  процессов».  В  Microsoft  это  еще  называли  быть  «бизнес-лидером»  —  тем, кто выигрывает, если проект имеет успех, и проигрывает, если он терпит неудачу. Боггс и Стив Линдеман (старший менеджер консолидации) посетили  конференцию  пользователей  SAP,  чтобы  больше  узнать  о  трудностях  внедрения.  Как заметил Линдеман: Мне повезло,  что я участвовал  в проекте с самого начала.  Бухгалтерии  было бы  проще возложить все это на отдел информационных услуг.  Мы  со Скоттом  пошли  на ежегодную  конференцию SAP  в прошлом году, и там все компании говорили то же самое. [Не возлагайте  все  на  ИТ-подразделение.]  Мы  переглянулись  и  решили,  что мы не допустим эту ошибку. На  конференции  стало  понятно,  что  система  R/3  очень  сложна. Было  также  очевидно,  что  при  внедрении  программного  пакета  полезно  иметь  людей  с  опытом  его  внедрения.  В  результате  Коннорс нанял  на  должность  проектного  директора  по  внедрению  SAP  Грега Дж.  Хармона  из  крупной  консалтинговой  фирмы.  Эйдан  Вейн  из  ITG был  назначен  проектным  менеджером  по  внедрению  NT  SAP.  Эти проектные  менеджеры  сидели  в одном  помещении  и делили  обязанности по договоренности. Лидеры проекта имели крайне напряженный  график работы.  Была  поставлена  задача  завершить  проект  через девять  месяцев.  Бюджет был  небольшим,  но  менеджерам  разрешили  использовать любой внутренний  персонал,  который  им  понадобится для  реализации  проекта.  Проектные  менеджеры  сами  провели  собеседования  и  отобрали  проектный  персонал.  Однако  финансовая  организация,  имевшая небольшой  персонал,  не  могла  позволить себе заменить людей,  выбранных  для  участия  в  проекте,  и  эти  члены  проектной  команды должны  были  выполнять  одновременно  две  штатные  работы.  В  основном,  эта  схема  работала,  хотя,  как  заметил  один  из  членов  про-

155

ERP  СИСТЕМЫ

ектной команды: «Во время завершения финансового цикла [в конце месяца]  мы их часто теряли». Члены проектной команды Microsoft также работали с несколькими группами консультантов и производителей. Как заметил Хармон: Производители необходимы, но слишком полагаться на них не стоит... Компании, использующие консультантов для установки SAP, рискуют. С консультантами внедрение сначала идет быстро [потому что они уже обучены и знают этот пакет программ].  Но риск в том, что собственный персонал не обучен, чтобы проводить обслуживание пакета. Чтобы  внедрение  шло  быстро,  и для  обучения  собственных сотрудников  работе  с  пакетом  программ,  члены  проектной  команды Microsoft работали с консультантами и наняли людей со стороны, уже имевших опыт работы с SAP. При внедрении SAP в Microsoft, в конечном счете, было задействовано примерно одинаковое число специалистов в финансовой области, служащих подразделения ИТ и внешних консультантов.

Реинжиниринг «с  маленькой  буквы» Microsoft решила внедрить SAP без модификаций.  Компания хотела  воспользоваться  преимуществами  лучших  практик,  имевшихся в  системе.  Эйдан  Вейн  назвал  этот подход «реинжинирингом  с  маленькой буквы с системой SAP  R/3 в  качестве движущей силы  изменений». Вейн сказал: Эта компания постоянно меняется. Можно даже сказать, что у нас хроническая болезнь неупорядоченности  вследствие недостаточного внимания. Мы не можем позволить себе роскошь проведения тщательного инжиниринга процессов. Основной принцип нашего проекта — получить быстрый результат и улучшить его по ходу работы. На все дается один год. Так как Microsoft  не переделывала SAP,  можно было более точно определить время, требующееся на установку программного пакета. Однако,  несмотря  на  решение  не  модифицировать  SAP,  проект был обширным:  нужно  было  установить 3  000 таблиц  параметров,  отражающих бизнес компании Microsoft. Хотя при реализации проекта ко-

156

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

личество  отдельных  финансовых  приложений  системы  было  значительно  уменьшено  (с  24  до  5),  необходимы  были  интерфейсы  для присоединения  финансовых  программ,  не  относящихся  к  системе SAP,  к БД SAP. Держаться принятого решения не переделывать SAP было трудно. Модель  организации,  используемая  в  SAP,  не совпадала с  моделью, применяемой  в  Microsoft.  Например,  в  SAP  не  используется  термин «подразделение».  Вместо  этого  в  R/3  применяются  термины  «центр прибыли»  и  «центр затрат»  (каждый  из которых обозначается  кодом). Так как проектная команда не хотела модифицировать программу, при установке системы SAP все подразделения Microsoft пришлось определить или как «центры прибыли»,  или как «центры затрат». Кроме того, SAP использует бизнес-модели, отличные от бизнесмоделей, используемых Microsoft. Например, SAP применяет концепцию «внутренних заказов» для операций внутри организации, которые присущи  матричной бизнес-модели  Microsoft.  Однако  Microsoft требовалось,  чтобы  внутренние  заказы  относились  к  подразделениям, продукции и проектам. Финансовый отдел хотел использовать три поля для классификации финансовых операций, но внутренние заказы в системе SAP имели только одно поле.  Использование существующей бизнес-модели Microsoft потребовало бы модификации системы SAP. Альтернативный  вариант подразумевал  создание  однозначных  кодов для каждой из одно- двух- и трехсоставной комбинации бизнес-категорий  —  комбинаторный  кошмар,  который  фактически  невозможно запомнить финансовому персоналу организационных единиц.  Кроме того,  коды  внутренних заказов  постоянно  менялись бы.  Далее,  если бы таблицы кодов поддерживались в главном офисе, то персонал на местах мог бы  столкнуться со значительными задержками доступа к операциям.  Таким  образом,  чтобы  схема с использованием  единственного  поля для  описания  внутренних заказов работала,  проектной команде  пришлось  разрешить  дочерним  компаниям  создавать  при необходимости новые комбинации. К  сожалению,  такие  компромиссы  при  внедрении  уменьшили стандартизацию,  которую  корпорация  Microsoft  пыталась  ввести  в свою структуру расчетов в мировом масштабе. Стив Линдеман сказал: Это очень болезненное решение. Оно не давало мне спать ночью. То, как мы это сделали, было наименее плохим вариантом. Он соответствует потребностям бизнеса,  но не является самым хорошим решением. Меня волновали люди, которым пришлось работать со  всеми  этими  кодами.  Следующая  версия  R/3  предоставляет

157

ERP СИСТЕМЫ

большую гибкость в работе с внутренними заказами. Установим ли мы ее? Мы еще не внедрили имеющуюся. Это очень непростое решение. Замена была бы сложной.

Обучение Несмотря  на все усилия  интегрировать свой  персонал в  процесс разработки, Microsoft пришлось значительно увеличить затраты на обучение. Система SAP R/3 потребовала значительного обучения. В итоге проектная  команда  по  внедрению  SAP  перепланировала  обучение  и сделала его максимально кратким и быстрым. Новое обучение совмещало получение бизнес-знаний с развитием умений пользования SAP. Согласно Линдеману: «Я 20 раз проводил шестичасовой курс обучения вводу учетных данных в SAP. Это был такой же курс обучения бухгалтерскому учету, как и обучения пользованию системными средствами». Обучение пользованию SAP требовалось и для тех служащих,  которые  использовали  SAPSET  (стандартное  отслеживание  расходов). Microsoft пригрозила закрыть учетные записи* тех, кто не обучается. Этот  метод  явно  сработал.  Как  сказал  Стив  Линдеман:  «Нам  пришлось закрыть только около  20 счетов».

Внедрение В августе 1996 г. — девять месяцев спустя после начала проекта — установка SAP была завершена на 90%, затронув порядка с 1  000 фактических пользователей в главном офисе корпорации. Грег Хармон отметил; «Мы достигли всех намеченных целей. Это самый крупный проект в области информационных технологий, хорошо и в срок выполненный в компании Microsoft». На создание первичного годового отчета с системой SAP,  похоже, понадобились те же три недели, что и при использовании традиционных  систем.  Однако  Microsoft  ожидала,  что  в  будущем  время, затрачиваемое на первичный годовой отчет, значительно сократится. Кроме того, ожидалось, что последующее составление ежемесячных отчетов может быть сокращено до двух-трех дней.

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

158

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ ERP СИСТЕМ

Предполагалось,  что  из  более  20  000  служащих  компании Microsoft  пользователями  систем  SAP  по  всему  миру  стали  2000  работников  бухгалтерских  и  финансовых  служб,  занятых  в  продуктовых и  функциональных  подразделениях  корпорации.  Конечно,  предполагалось,  что  и  многие другие  пользователи  также  будут  использовать данные  системы  R/3.

Открытые  вопросы Хотя  внедрение  считалось  успешным,  существовали  незакрытые вопросы,  к которым  проектная команда должна была еще обратиться.

Распространение в мировых масштабах Начиная  с  августа  1996  г.,  и  все  последующие  12  месяцев Microsoft  планировала  распространить  SAP  среди  своих  дочерних компаний  по  всему  миру.  Планировалось,  что  большинство  этих фирм  фактически будут использовать ту же модель.  Как сказал  Вейн: Никто не говорит,  что SAP хуже,  чем старая система. Дочерние компании  испытывали довольно сильный голод в возможностях.  И у них был  год на установку SAP.  Некоторые дочерние  компании думают, что они  могут сделать это лучше самостоятельно, что они вполне автономны.  Но мы не предоставляем им ресурсов для значительных изменений. Microsoft довольно автократическая компания, когда дело доходит до отчетности  перед центром, особенно в финансах.  Мы предоставили  им  33  таблицы,  которые  они  могут  конфигурировать [для  отражения  местных  потребностей  и  различных  путей  ведения бизнеса]. Здесь [в главном офисе] мы конфигурируем 3 000 таблиц.

Кадры Кадры  —  следующая  область,  в  которой  будут заменяться  традиционные приложения.  Хотя СЮ Джон  Коннорс говорит о себе,  как о  «большом  стороннике  SAP»,  он  полагает,  что  приложение  для  управления  кадрами  в  SAP  недостаточно  соответствует потребностям Microsoft.  Кроме того, сотрудники департамента управления  персоналом  предпочитает  модуль  системы  PeopleSoft  соответствующему модулю  SAP.  Коннорс  сказал:  «На  следующей  неделе  я  собираюсь посетить  SAPPHIRE  [конференция  пользователей  SAP].  Я  хочу  узнать  насчет того,  что  они  собираются  делать  с  модулем  управления кадрами».

159

ERP  СИСТЕМЫ

Отсутствие изменений в процессах закупок Некоторые члены  группы  со стороны финансового отдела выразили озабоченность отсутствием изменений в санкционировании во внутреннем процессе закупок. Например, то, что любой служащий мог потратить до  1  000 долларов без санкционирования,  осталось без  изменений.  В  основном  контроль осуществляли  менеджеры,  управляющие подконтрольными  им  ресурсами.  ГрегХармон  объяснил,  что  риск был относительно небольшим:  «70%  наших операций оцениваются  в сумму менее  1  000 долларов,  но  они  составляют только  2%  наших  расходов. Если  мы  и  ослабили  контроль,  то только  контроль за  расходами...»

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

Литература Wallace,  P.  (1995).  «Microsoft's  Finance  Department  Gets  Up  to  Speed». InfoWorld, June 5, p.58.

Вопросы 1. Каков риск для Microsoft в данном начинании? 2. Почему не были успешными первые два внедрения ERP системы? 3. Насколько важно задействовать бизнес-сферы в ERP системах? 4.  Объясните  понятие  реинжиниринг  «с  маленькой  буквы».  Что  будет  называться  реинжинирингом «с большой буквы»? 5. Обдумайте компромиссы при внедрении. Было ли их слишком много? Почему да/нет? 6.  Было ли начинание успешным?  Почему да/нет? 7.  Должна  ли  корпорация  Microsoft  внедрять  модуль  управления  кадрами SAP? Почему да/нет?

760

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

10 ПРОЕКТИРОВАНИЕ  ERP  СИСТЕМ Выбор стандартных моделей, объектов и процессов Одним  из  критически  важных  решений,  которые  нужно  принять  в  отношении  любой  ERP  системы,  это  выбор  общих  стандартных  МОПов,  т.  е.  моделей  (например,  моделей  организации), объектов  (например,  планы  и  списки  поставщиков)  и  процессов (например,  управление  заказами).  Выражения  «общие  ...  и  глобальные»  и  «реализуемые  многими»  стали  рассматриваться  в  некоторых  компаниях  как  определяющие  для  помощи  при  внедрении  этих  общих  МОПов  (см.  СЮ  1996).  Вместо  того  чтобы,  учитывая  предшествующую  деятельность  каждой  организационной единицы,  выбирать  для  нее  свои  собственные  МОПы,  как  это  часто  делается  в  традиционных  системах,  компания,  имеющая  ERP систему,  будет  использовать  одни  и  те  же  МОПы  для  каждой  организационной  единицы.  Однако  выбор,  внедрение  и  использование  общих  МОПов  —  задача  непростая.  Из-за  этих  МОПов  в фирме  возникнут  противоречия.  Поэтому  в  данной  главе  мы  обращаемся  к  следующим  вопросам. •  Почему  МОПы  важны? •  Откуда берутся  общие  МОПы? •  Почему фирмам  необходимы  общие МОПы для  ERP систем? •  Почему фирмы  не имели общих МОПов до  ERP систем? •  Почему трудно  выбрать общие стандарты? •  Каковы некоторые мотивы  выбора? •  Какие  методы  были  использованы  для  выбора  общих  ERP МОПов, чтобы разработать такие «общие... и глобальные» процессы, чтобы их «реализовывали многие»?

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

161

ERP  СИСТЕМЫ

Откуда берутся общие МОПы? Откуда берутся стандартные объекты и процессы? В данном параграфе кратко изложены  интервью с двумя  крупными фирмами относительно источника их общих МОПов. Из  беседы  с  ERP  проект-менеджером  компании  Nestle  (Соединенные  Штаты)  стало  известно,  как  эта  фирма  выбирала  варианты бизнес-процессов при внедрении SAP. Во-первых, она решила, что во всех трех ее отделениях в США будут внедрены общие МОПы.  Во-вторых,  «кандидатами»,  которые  должны  были  подвергнуться  оценке, стали  МОПы,  существующие в каждом  из трех отделений.  В-третьих, для  формирования  МОП-кандидатов  были  использованы  БД  лучших практик, предоставленные как системой SAP, так и привлеченные консультантом.  В  некоторых случаях были  разработаны  смешанные  МОПы,  информация  для  создания  которых  бралась  из  разных  источников.  В-четвертых,  команда,  состоявшая  из  специалистов  разных функциональных подразделений,  использовала оба этих набора  МОПов для выбора стандартных объектов и бизнес-процессов компании. Из  беседы  с  заместителем  ERP  проект-менеджера  компании Litton Data Systems выяснилось, что такой же метод был использован этой компанией для создания набора стандартов при внедрении системы BAAN, но источник стандартов был несколько иным из-за специфических требований производства.  Как и в компании Nestle, для создания и оценки вариантов выбора была создана группа, состоявшая  из специалистов разных функциональных подразделений.  Однако,  поскольку  компания  Litton  Data  Systems  участвует  в  нескольких проектах  для  федерального  правительства  (в  дополнение  к другим источникам), ей были необходимы также специфические «федеральные»  МОПы,  которые соответствовали  бы  определенным  нормативным  документам  (например,  требования  отчетности для  государственных контрактов).

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

162

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

Почему фирмам необходимы общие МОПы для ERP систем? В отличие от локального ПО, созданного на заказ, ERP системы — это  готовое  («коробочное»)  ПО,  спроектированное  и  разработанное для внедрения во многих компаниях и, более того, для интеграции всех подразделений  и  предприятий  компании,  для  создания  общего для всей  корпорации  представления  данных.  Как  заметил  Браунли (Brownlee  1996,  с.  R18):  «Когда служащие  компании  Colgate  входят в сеть, у них на экране появляются одни и те же опции, неважно, находятся они в Кембридже, Берлингтоне или Нью-Йорке». Таким  образом,  ERP  системы  обеспечивают  общими  МОПами. Но  почему фирмы  нуждаются  во внедрении общих МОПов при внедрении  ERP  систем?  В  данном  параграфе  рассмотрены  некоторые причины, собранные из различных примеров внедрения  ERP: •  требования со стороны  ПО; •  повышение уровня обслуживания  клиентов; •  восстановление управления  процессами; •  необходимость общего представления данных в организации; •  получение прибыли и сокращение расходов.

Требования со стороны ПО Возможно  самой  непосредственной  причиной  внедрения  стандартных ERP объектов и процессов является то, что этого требует ПО этих  систем.  Как  сказал  вице-президент  компании  Red  Pepper

163

ERP СИСТЕМЫ

Software: «He важно производит предприятие сталь,  каучук или электронику — 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  эту возможность, позволяя персоналу отдела продаж увидеть, что доступно на  любом  предприятии  или  складе,  и  быстро  собрать  заказы  для клиентов.

Восстановление управления процессами В  некоторых  случаях  различные  территориально  распределенные  подразделения  организации  используют  процессы,  кото-

164

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ ERP СИСТЕМ

рые  производят  впечатление  вышедших  из-под  контроля.  Фирмы,  как  видно  на  примере  компании  Vandelay,  внедряют  ERP  системы,  чтобы  восстановить  контроль  над  этими  процессами  и чтобы  организация  внедрила  лучшие  практики  (McAfee  and Upton  1996,  с.4-5): Практика  выполнения  операций  географически  разделенными подразделениями компании Vandelay была так же разнообразна, как и  используемые  ею  информационные  системы.  Не  было  единообразных, признанных «лучшими» методов выписывания счетов клиентам,  закрытия  счетов в конце месяца,  резервирования  запасов на складе  под  заказ  клиента  или  выполнения  сотни  других  действий производственного  процесса,  которые  требовали  использования компьютера или ввода данных. Для  решения...  проблем,  связанных  с  системами  и  установленными  порядками,  компания  Vandelay  решила  купить  и  установить  единственную  ERP  систему,  которая  объединила  бы функции  всего,  ранее  разрозненного  ПО.  Компания  также  собиралась  стандартизовать  деятельность  географически  разделенных  подразделений.

Общее представление данных Некоторые  фирмы  пытаются  произвести  внедрение  ERP  системы  при  наличии  у  каждой  организационной  единицы  собственных объектов.  Однако  большинство  фирм,  выбирающих  ERP,  хотят  избежать  негативных  последствий  использования  различных  и  фрагментарных  МОПов. Чтобы  создать  общее  представление  данных,  необходим  набор общих организационных объектов (например, списки поставщиков и клиентов).  Эти объекты дают возможность сбора информации в различных  условиях  и  сохранения  при  этом  общего  представления  информации. Например, как сказал Вон (Vaughn  1996, с. 74): Компании Elf Atochem North America Inc.  в Филадельфии переводят на работу с системой SAP 13 организационных единиц... Корпорация  пришла к этому решению,  так как ее  различные компании были  реорганизованы  для  того,  чтобы  начать  работать  как  единая компания.  В результате эта компания унаследовала «много различных компьютерных систем и путей  ведения  бизнеса».  Общее представление  разнообразных данных было  важно...

165

ERP  СИСТЕМЫ

Получение прибыли и сокращение расходов Внедрение  стандартных  объектов  и  процессов  может  принести прибыль и сократить расходы.  Например, как сказал руководитель ITподразделения  компании  Pirelli  Ариго  Андреони:  «Чем  больше  стандартизации,  тем  легче реализовывать  новые  идеи  и  реагировать  на новые возможности» (Wakin 1998, с. 48). Андреони также отметил, что стандартизация  может  уменьшить  расходы.  Например,  до  стандартизации  компания  Pirelli  имела  универсальные  вспомогательные офисы и созданное на заказ ПО в каждой из пяти стран. ПО планирования  ресурсов предприятий  было  использовано для  замены  персонала  многочисленных  бэк-офисов  персоналом  единственного  бэкофиса в  Швейцарии с  сокращением  расходов  на 25%.  В  настоящий момент офисы в каждой из стран отсылают данные центральным серверам компании.

Почему трудно  выбрать  общие  стандарты? Так  как  ERP  системы  разработаны  для  предприятия,  их  внедрение требует принятия  множества решений,  включая  выбор стандартных  объектов  и  процессов,  которые  будут  использоваться.  Например,  в случае с компанией Vandelay (McAfee and Upton  1996) для облегчения  взаимодействия  и  координирования  различных  организационных единиц, таких как фабрики и подразделения были  внедрены некоторые стандарты,  включая общую таблицу счетов, общие номера поставщиков  и  общие  номера  компонентов.  Однако  некоторые  МОПы  приносят неодинаковую пользу определенным  организационным единицам.  То,  что  принимается  для  всеобщего  использования,  не всегда  является  самым  лучшим  или  предпочтительным  на  местах,  в каждом подразделении. Например, Вон (Vaughn 1996, с. 72), цитируя Криса Руна,  вице-президента компании Red Pepper Software,  сказал: «Стандартные  объекты  ERP  системы  полезны,  если  пользователи финансовых  данных  хотят  консолидировать  информацию  множества организационных  единиц,  но...  для  конкретных  подразделений  общее  представление данных  может быть  неоптимальным».  Стандартизация  процессов  и  объектов  ERP системой  приводит к общим  положительным  результатам,  но некоторые из них появляются за счет потерь  местных специфических  возможностей. Более  того,  из-за  разницы  для  корпорации  и  подразделений  в выгодах,  создаваемых  выбранными  стандартными  объектами  и  процессами,  групповое  принятие  решений  может  стать  политическим

166

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

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

167

ERP СИСТЕМЫ

Насколько отличаются стандарты подразделений от корпоративных стандартов? Какой процент МОПов допустим для формирования подразделениями?  Цифра,  возможно,  варьируется  от организации  к организации.  Однако,  как  было  замечено  при  обсуждении  компании  Owens Coming  (CIO  1996),  всегда  есть  исключения  из  правила  «общие  ...  и глобальные»:  «С  SAP  всегда  будут  вариации  в  процессах  на  уровне организационных единиц, особенно касающиеся клиентов... Моя работа — гарантировать,  чтобы эти  вариации были скорее исключением, чем правилом». При внедрении системы компанией Microsoft головной  офис  сформировал  3  000 таблиц,  в  то  время  как локальным офисам  разрешили  формировать  примерно  30  таблиц  (Bashein, Markus, and Finley 1997).

Насколько серьезно подразделения и корпорация осуществляют процесс выбора? Выбор общих МОПов — это серьезное дело для всех его участников. В некоторых случаях процесс выбора может стать очень эмоциональным.  Например,  в случае внедрения системы  компанией Owens Corning (White и др.  1997) возник серьезный конфликт из-за объекта: Однако SAP R/3  потребовала,  чтобы  персонал  Сесере  использовал единственный список продукции и единственный прайс-лист. Персонал сначала сопротивлялся передаче контроля над установлением  цен  и  маркетингом  центральной  команде,  располагающей компьютерами. «Моя команда готова была [меня] убить, если бы мы им уступили», — сказал он. Таким  образом,  для  фирм  может  быть  важно  попробовать  выбрать МОПы, используя систематический подход.

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

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

168

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ ERP СИСТЕМ

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

Минимизация затрат подразделения на изменения. Вместо того, чтобы максимизировать корпоративную пользу, подразделение  может работать на сохранение  своих собственных объектов  или процессов для того,  чтобы  минимизировать затраты  на изменения, такие как обучение  имеющегося  персонала или найм нового для использования  (или  внедрения)  новых стандартов.  Подразделение,  не добившееся  продвижения  своих собственных стандартов  в  качестве корпоративных,  может  все же  минимизировать свои  затраты  на  изменения, выбрав стандарт, наиболее близкий к собственному. Реагирование  на  конкуренцию.  Глобальная  конкуренция  вынудила  многие  компании  начать пользоваться  услугами  сторонних организаций взамен услуг, ранее предоставляемых собственными подразделениями.  Поэтому  подразделение,  столкнувшееся  с  потенциальной угрозой ликвидации,  может отреагировать на нее осуществлением  обширного  реинжиниринга.  Соответственно,  в  этом  случае подразделения  могли  бы  работать  на  реализацию  значительных  изменений стандартных объектов и процессов (см., например, Hammer 1990). Указанные  причины  дают  основание  предполагать,  что  подразделения  имеют стимулы  склонить корпорацию  к выбору стандартов, благоприятных для конкретных подразделений. Таким образом, компаниям  необходимо  подумать  о  том,  как  выбрать  эти  общие  и  глобальные  стандарты.

Методы выбора стандартов Как  организации,  внедряющие  ERP  систему,  выбирают  общие объекты и процессы? Как было отмечено, существует множество источников  ERP стандартов,  и затраты для  конкретных подразделений будут варьироваться в зависимости от того, какие стандарты выбраны для внедрения. Как  организации  решают,  какие  стандарты  (например,  списки поставщиков или продукции) принять? Как отмечают МакАфи и Аптон (McAfee and Upton  1996), у компаний есть вопросы относительно того, как выбирать стандарты для ERP систем. Например, авторы цитируют проект-менеджера,  который говорит, что он отдает предпочтение  МОПам,  «реализуемым  многими,  разработанным  немногими»,

169

ERP  СИСТЕМЫ

но не знает,  как реализовать это выражение на практике.  Как достигается  «реализуемый  многими»?  Какие  правила  группового  выбора использовали  фирмы? Решение  большинством  голосов Согласно Вокину (Wakin 1998), СЮ компании Pirelli, там используется то, что он называет «демократическим управлением» подразделениями для достижения стандартизации в ключевых сферах бизнеса, необходимых для внедрения ERP. Хотя демократическое управление  может принимать  многие  формы,  он  предполагает  подход «выбор  большинства»  —  какой  бы  стандарт  ни  выбрало  большинство подразделений, он становится корпоративным стандартом. Правило «выбор  большинства»  —  это  такое  правило,  при  котором  компания принимает МОП х вместо МОПа у, если большинство подразделений предпочитает МОП х. Правило  Борда Альтернативным  методом  выбора  «ввода  многими»  является (а)  голосование  членов  группы  специалистов  путем  ранжирования вариантов  по  убывающей,  и  затем  (б)  суммирование  количества первых  мест  (вторых  мест  и  т.  д.),  полученных  каждым  вариантом. Например,  если существует пять различных путей  реализации бизнес-процесса  «резервирование  запасов  для  клиентов»,  то  каждый член группы оценит варианты баллами от 1  до 5.  Каждое полученное процессом  1 -е место оценивается в 5 баллов (2-е место — в 4 балла и т. д.). По правилу Борда (см., например, Fishburn 1997) выбранным  считается  вариант,  получивший большее количество баллов. Из  интервью  с  заместителем  директора  компании  Litton  Data Systems по внедрению системы PeopleSoft выяснилось, что компанией  был  использован  метод,  похожий  на  правило  Борда.  Во-первых, компания  определила  «ключевые аэрокосмические  и  оборонные характеристики и обязательства», среди них: (1) бизнес-процессы оборонной промышленности; •  правительственные формы, •  промежуточные  выплаты, •  скользящее среднее значение фактической стоимости; (2)  финансовое управление: •  бюджетирование и планирование ресурсов подразделений, •  управление издержками, •  соотношение между накладными  расходами  и оплатой труда.

170

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ ERP СИСТЕМ

Во-вторых,  после  получения  этих  и других требований,  различные производители  ERP  систем были  оценены  и  ранжированы  в соответствии с их возможностями обеспечения каждой из характеристик.  При этом соответствующим  местам были присвоены баллы (как только  что  было  описано).  В-третьих,  был  сделан  выбор  ERP  системы,  исходя  из окончательной оценки,  определяемой общей суммой баллов. Оптимальность  Парето Как  отмечалось  выше,  СЮ  компании  Pirelli  осуществляет,  как  он говорит,  «демократическое управление» для  достижения  стандартизации  в  ключевых сферах бизнеса,  необходимой для  внедрения  ERP (Wakin  1998).  Оптимальность  Парето  —  это  критерий  выбора  из  пар стандартов ERP путем оценки преимуществ для каждого подразделения.  Конечно,  если  все  организационные  единицы  остановятся  на процессе х,  а не у,  то  выбирается  процесс х.  В  более типичном  случае,  когда  подразделения  не  соглашаются  на  оказание  поддержки различным  процессам,  решение  «оптимальность  Парето»  является выбором, когда ни один другой выбор не может (а) удовлетворить ни одно подразделение в большей  степени без того,  чтобы  не  (б) удовлетворить любое другое подразделение,  пусть в меньшей степени. Диктатура В других ситуациях очевидно,  что решение,  использованное  при выборе  стандартов  ERP  системы,  ближе  не  к  подходу  «выбор  большинства», а к диктатуре. Например, при обсуждении компании Owens Corning  было отмечено:  «Команде Толедо было бы  сравнительно легко  собраться  и  выбрать  процессы  SAP для  компании  в  одностороннем  порядке»  (СЮ  1996). Другой пример (Brownlee 1996) — компания Colgate, внедрившая сеть  запасов,  «управляемых  поставщиками»  (для  своих  клиентов  и поставщиков),  используя  SAP.  Colgate  обеспечила  нескольких  своих самых важных поставщиков системой  SAP,  чтобы они могли  получить непосредственный доступ к ее ERP системе.  В результате ей не нужно платить за ингредиенты  продуктов,  пока она их действительно не использует.  В  данной  ситуации  Colgate  определила  многие  бизнеспроцессы,  предоставила  стандарты  в  отношении  различных  прайслистов и т. д. Подразделение может стать «диктатором»,  если это подразделение  корпоративного  офиса  с  определенным  видением  мира  или большое  подразделение с относительно значительной  властью.

171

ERP  СИСТЕМЫ

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

Резюме До внедрения 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,  P.  (1971).  «A  Comparative  Analysis  of  Group  Decision  Methods». Behavior Science, November, pp. 538-44.

172

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ ERP СИСТЕМ

Hammer,  M.  (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  систем.  В данной  главе рассматривается  значение  этих двух  понятий,  некоторые характеристики  каждого  из  методов  и  некоторые  их  достоинства  и  недостатки. Здесь также анализируется выбор методологии внедрения с учетом  размера организации,  ее сложности и структуры,  а также с точки зрения объема внедрения.  Наконец, обсуждаются  некоторые дополнительные  понятия  и  методы,  используемые  при  внедрении ERP  систем.

Что значит внедрение «сразу»? При  внедрении  «сразу»  полный  набор  приложений  ERP  внедряется  во всех подразделениях одновременно.  При внедрении «сразу» система из тестовой версии превращается в настоящую систему, используемую для  проведения  операций,  за считанные дни  (отсюда  и название  «сразу»).  Этот  подход требует одновременного  внедрения множества модулей.  В случае компании Quantum (см. приложения к данной  главе)  это  означало  внедрение  17  модулей  приложений Oracle в 23 подразделениях по всему миру за время, равное примерно неделе. В соответствии с этим сценарием внедрение «сразу» требует выполнения до перехода от традиционных систем к новой системе  многочисленных  тестирований.  В  случае  с  компанией  Quantum это  означало  от  шести  до  восьми  месяцев  тестирования  системы,

173

ERP СИСТЕМЫ

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

Что  такое  поэтапное  внедрение? Метод поэтапного внедрения — это метод, при котором внедряется  один  модуль из  группы  модулей,  причем  зачастую только  в одном  подразделении.  Поэтапное  внедрение — это  последовательное внедрение,  состоящее  из  проектирования,  разработки,  тестирования и установки различных модулей.  В отличие от внедрения «сразу», поэтапное  внедрение  требует,  чтобы  было  уделено  значительное внимание традиционным  системам  и  проводилось  их обслуживание для обеспечения  (на каждой стадии) их интеграции с новой ERP системой. По  сравнению  с  внедрением  «сразу»  поэтапному  методу  соответствуют  более  мелкие  «доли»  проектирования  процессов  и  объектов  модулей,  их  разработки,  тестирования  и  внедрения.  Компания Siemens,  например,  использовала  трехэтапное  внедрение  SAP  (Hirt and Swanson  1998).  На первом этапе компания  внедрила модули финансов,  управления,  дебиторской  и  кредиторской  задолженности  и модуль закупок.  Работы по проектированию,  разработке, тестированию и внедрению для первого этапа должны были завершиться в период с октября 1995 г. по сентябрь 1996 г. На втором этапе, в период с  октября  1996  г.  по  апрель  1997  г.  должны  были  быть  установлены модули  управления  материалами,  производственного  планирования и  планирования  качества.  Наконец,  остальные  модули  планировалось спроектировать,  разработать,  протестировать и  внедрить в период с апреля 1997 г. по сентябрь 1997 г.

174

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ ERP СИСТЕМ

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

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

Меньший риск При поэтапном внедрении члены команды задействованы в разных этапах внедрения различных модулей.  При внедрении же «сразу» вся проектная команда работает над проектом примерно в одно и то же время. Таким образом, некоторые (например, Хенк Делевати, СЮ компании  Quantum)  заявляют,  что  метод  внедрения  «сразу»  имеет меньший  риск по сравнению с  поэтапным  внедрением:  «Поэтапный подход  более  рискован,  поскольку  не  возможно  вовлечь  всех  и координировать  их  действия»  (Radosevich  1997).  Кроме  того,  при подходе  «сразу»  риск  потерять  служащих  до  завершения  их  обязательств  по  внедрению  меньше.  А опыт участников  внедрения до его завершения  не  является  «полным».  Таким  образом,  при  подходе «сразу»  вероятность  того,  что  участники  внедрения  останутся  на фирме до его окончания, более высока.

Объединение функциональных возможностей Желаемая  функциональность  может  потребовать  стыковки множества  модулей.  В  этом  случае,  прежде  чем  функциональные характеристики  станут  доступными,  такие  модули  должны  быть

175

ERP  СИСТЕМЫ

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

Обратной дороги нет При внедрении «сразу» традиционной системы, к которой можно вернуться,  больше  не  существует.  Таким  образом,  фирмы  должны продвигаться вперед с новой системой, даже если есть определенные проблемы.  Зная, что дороги  назад нет,  проще не оглядываться. Это  также  может  обеспечить  приверженность  системе,  которой,  в противном случае, могло бы не быть.

Более быстрое внедрение Одной  из  причин  неудачных  проектов  внедрения  ERP  систем является  слишком  продолжительное  (зачастую длящееся  1-3  года) внедрение.  Длительное  внедрение  может  не  оказаться  успешным по  нескольким  причинам.  Чем  больше  времени  занимает  внедрение,  тем  (а)  изменится  большее  число требований,  (б)  больше  вероятность того, что персонал, задействованный во внедрении, сменится,  и (в) больше времени будет у оппонентов проекта на работу против него. Хотя  на  продолжительность  внедрения  почти  всегда  влияет объем  ресурсов,  задействованных для  выполнения задачи,  ни  подход «сразу»,  ни поэтапный  метод не занимают однозначно большее совокупное время на внедрение. Однако, так как при подходе «сразу»  проектирование,  разработка,  тестирование  и  внедрение  всех модулей  проходит одновременно,  внедрение  при  этом  обычно  занимает меньше времени. Такое внедрение может проводиться быстрее  также  благодаря  отсутствию  необходимости  создавать временные интерфейсы  с традиционными  системами  (как  при  поэтапном внедрении).

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

176

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

Каковы  преимущества  поэтапного  внедрения? Пиковые требования к ресурсам меньше, чем при внедрении «сразу» Некоторые  фирмы,  такие  как  Siemens  (Hirt  and  Swanson  1998), выбрали поэтапный  метод из-за ограниченности ресурсов.  В то время  как  метод  «сразу»  требует  единовременного  использования  ресурсов  значительного  объема,  при  поэтапном  методе  эти  пиковые требования  к  ресурсам  можно  распределить  по  этапам.  При  таком внедрении  ресурсы,  требующиеся  для  любого  конкретного  этапа, могут  быть  ограничены  и  быть доступными даже для  организаций  с самыми ограниченными ресурсами.

Для какого-то конкретного модуля могут быть выделены большие ресурсы При необходимости фактически все ресурсы фирмы на проектирование,  разработку  и  тестирование  могут  быть  сосредоточены  на одном  конкретном  этапе  и  модулях,  внедряемых  на  этом  этапе.  В этом  состоит  отличие  поэтапного  внедрения  от  внедрения  «сразу», при  котором  ресурсы  должны  быть  одновременно  распределены между многочисленными модулями. Этот вопрос может быть важным для  фирм  с  ограниченными  ресурсами  или  резервом  времени.  При отсутствии достаточных ресурсов проект может подвергаться  значительному  риску  неудачи.

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

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

177

ERP  СИСТЕМЫ

чена. Поэтапный метод, таким образом, более консервативен, так как он  обеспечивает дублирование.

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

Проект-менеджеры могут продемонстрировать работающую систему При поэтапном внедрении,  чтобы показать остальной компании, что  система  работает,  может  быть  использовано  успешное  внедрение какого-либо модуля.  Получение хороших результатов может быть необходимо  в ситуациях,  когда  поначалу не существует полной  поддержки  проекта  организацией  или  ее  топ-менеджментом.  Успех  на одном  этапе  может  быть  использован  для  демонстрации  менеджменту того,  что система может и будет работать. Если  это  основная  причина,  по  которой  фирма  использует  поэтапный  метод,  скорее  всего  в  первую очередь будут внедрены  «самые простые»  модули.  Например,  в  первую очередь будут внедрены модули,  требующие  проведения  лишь  минимального  реинжиниринга.  Это  можно  увидеть  на  примере  компании  Siemens  (Hirt  and Swanson  1998),  где возможности первого внедренного программного пакета почти полностью соответствовали требованиям фирмы.

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

178

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

Каковы  недостатки? Подход «сразу» Недостатки подхода «сразу» прямо противоположны  преимуществам поэтапного внедрения: •  могут потребоваться огромные пиковые ресурсы; •  для конкретного модуля будет доступно меньше ресурсов; •  риск полного отказа системы может быть выше; •  нельзя без труда вернуться к традиционной системе; •  у  персонала  меньше  практической  возможности  приобрести знания; •  проект-менеджеры  не  могут  показать,  что  система  работает, до полной ее установки; •  период  между  разработкой  и  внедрением  может  быть  более длительным.

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

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

179

ERP  СИСТЕМЫ

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

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

Малый 

Большой

Размер организации

Рис.  11.1.  Связь  между размером  и  сложностью  организации и  используемым  методом  внедрения

180

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ ERP СИСТЕМ

Размер  фирмы  также  может  зависеть  от  нескольких  факторов. Хотя классическая оценка фирмы — это доходы или общая стоимость имущества,  другими  факторами  могут  быть  количество  офисов  или географических  регионов,  в  которых  она  расположена.  Для  оценки размера организации могут быть также использованы ее продукция и клиенты. Малые,  менее  сложные  фирмы.  Менее  крупные  и  менее  сложные  фирмы  будут  иметь  меньшее  разнообразие  продукции  и  клиентов.  Таким  образом,  внедрение  ими  соответствующего  проекта  не является  таким  трудным,  как  в  более  сложных  фирмах.  Кроме  того, так  как  их  размер  небольшой,  а  проект  несложный,  риск  неудачного внедрения,  связанный  с  внедрением  «сразу»,  будет  меньше.  Соответственно,  так  как  внедрение  «сразу»  в  целом  проходит  быстрее  и требует  меньших  расходов,  менее  крупные  и  сложные  фирмы  могут эффективно  использовать  этот  метод. Крупные,  более  сложные  фирмы.  Если  фирма  очень  крупная  и сложная,  то,  скорее  всего,  будет  использовано  поэтапное  внедрение,  а не внедрение «сразу».  Размер и сложность организации  могут сделать  или  слишком  сложным  метод  внедрения  «сразу»,  или  слишком  высоким  риск провала, что приведет ее к выбору поэтапного метода.  Аналитики  (такие,  как  Бобби  Кэмерон  из  Forrester  Research) предположили,  что  большинство  крупных  фирм  используют  одну  из версий  поэтапного  внедрения  и  что  только  небольшое  количество крупных  фирм  используют  внедрение  «сразу»; Слишком  сложно — особенно для  крупных компаний — осуществлять крупный проект,... и риск с точки зрения проектного менеджмента — высок... Огромные проекты одновременного внедрения достаточно  сложны,  и  большинство  стремятся  к  менее  крупному  постепенному внедрению.  (Radosevich  1997). Кроме того, для  крупных фирм требования  пиковых ресурсов для внедрения  могут оказаться  слишком  высокими.

Иерархия организации и управление Даже  если  все  остальные  организационные  аспекты  одинаковы, при  выборе  методологии  должна  учитываться  иерархия  и  управляемость организации.  В  целом,  по  мере  того,  как организация  становится  более  иерархической  с  большей  управляемостью,  она  все больше  становится  способной  выдержать  поэтапное  внедрение.  Это отношение  представлено  на  рисунке  11.2.

181

ERP  СИСТЕМЫ

Низкая 

Высокая

Степень управляемости

Рис.  11.2.  Связь  между  иерархией  и  управлением  организации и  используемым  методом  внедрения Горизонтальная  организация  и  нежесткое  управление. Бобби  Кэмерон  из  Forrester  Research  предположил,  что  некоторые характеристики компании должны привести к использованию метода внедрения «сразу»:  «Если компания  имеет горизонтальную,  нежестко управляемую  организацию,  то  поддерживать  проект  на  протяжении поэтапного  внедрения  очень трудно»  (Radosevich  1997). Значительная  иерархия  и  жесткое  управление.  Если  структура  организации  имеет  значительную  иерархичность  (организация является «многоуровневой»),  и организация управляется жестко, то в организации  существует  значительный  аппарат для  проведения  поэтапного  внедрения.  Кроме  того,  из-за  наличия  организационной структуры  и  управления  на  местах  может  оказаться,  что  поэтапный метод  (без  значительного  реинжиниринга)  является  единственным политически приемлемым.

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

Число модулей Так как ERP системы состоят из модулей,  организации могут решить  внедрить  различные  модули,  которые  отвечают  их  требованиям.  Например,  корпорация  Microsoft при  внедрении SAP  R/3 устано-

182

ЧАСТЬ  ТРЕТЬЯ.  ЖИЗНЕННЫЙ  ЦИКЛ  ERP  СИСТЕМ

Минимальная 

Высокая

Степень  изменения  модулей  ERP Рис.  11.3.  Связь  между  методом  внедрения  и  модулями  ERP вила только финансовый модуль. Другие организации внедряют полный набор приложений ERP систем. По  мере  увеличения  числа  модулей  их  взаимодействие  становится  координировать  все труднее.  Кроме  того,  увеличиваются  ресурсы,  требующиеся  из  расчета  каждого  модуля,  выбранного  для внедрения.  В  результате  по  мере увеличения  числа модулей  происходит сдвиг от внедрения «сразу» к поэтапному внедрению.

Соответствие модуля: масштабы модификации В  некоторых случаях модули  могут требовать только ограниченной  модификации,  но  в других случаях может потребоваться значительная модификация. Например, как было отмечено в случае с компанией  Siemens  (Hirt and  Swanson  1998),  финансовые  модули  соответствуют требованиям  фирмы  на  100%,  а другие  модули только  на 70-80%, и, таким образом, требовалась некоторая модификация. По мере увеличения  масштабов  изменения модулей  предпочтение  будет  отдаваться  поэтапному  внедрению.  Если  используемые модули  фактически  остаются  такими,  как  их  задумал  и  разработал производитель, проблемы взаимодействия будут минимальными.

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

183

ERP СИСТЕМЫ

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

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

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

Внедрение «волнами» Компания  Tektronix  использовала  альтернативный  метод,  называемый волнообразным (Westerman и др.  1999). Внедрение ERP системы  этой  компанией  рассматривалось  как  программа  изменений, состоящая  из  различных  «волн»  изменений.  Каждая  «волна»  программы привносила в различные организационные единицы или географические  регионы  новые  исполняемые  функции.  Хотя  каждая волна управлялась независимо, чтобы гарантировать, что программа изменений  выполняется,  общая  проектная  команда  управляла  их взаимозависимостями. Например, компании Tektronix понадобилось три года на внедрение приложений Oracle. За первый год в  16 странах была внедрена Главная  книга.  Затем  компания сфокусировалась на конвертации дебиторской задолженности и управлении стоимостью в своих региональных учетных центрах по всему миру.  После внедрения  финансовых  приложений  Tektronix  смогла  добавить  новые возможности  (например,  отчеты о заказах,  биллинг и задолженности) в информацию о продукции своих организационных единиц.

184

ЧАСТЬ ТРЕТЬЯ.  ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

Ускоренный поэтапный метод Хотя некоторые организации (по каким-либо причинам) не хотят проводить внедрение «сразу», они все же могут использовать так называемый ускоренный поэтапный метод. Данный метод предполагает, что вре'менные связи с традиционными системами являются действительно вре'менными, а не почти неизменными.  Кроме того, при использовании данного метода одновременно могут быть внедрены несколько модулей.

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

185

ERP  СИСТЕМЫ

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

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

Литература Hirt, S., and Swanson,  E.  В. (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.

786

ЧАСТЬ ТРЕТЬЯ.  ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

Приложение  11-1 Quantum I: требования, выбор системы и метод внедрения* Хенк Делевати,  СЮ  и  вице-президент международной  информационной службы компании Quantum, заметил: Нам крайне важно соответствовать нашим клиентам и нести перед  ними  ответственность.  А  когда  дело  доходит  до  управления спросом и запасами в мировом масштабе [при использовании нашей информационной системы, у нас сделать это не получается]... В  результате,  для  реализации  своих  потребностей  компания Quantum  планировала  купить  систему  планирования  ресурсов  предприятий.  Ей необходимо было понять свои требования,  какое ПО им отвечает и  какой  метод внедрения  подойдет больше.

Quantum Компания  Quantum,  главный  офис  которой  расположен  в  Милпитасе,  штат  Калифорния,  имела  доход  в  4,4  млрд.  долларов.  Она была одним  из  крупнейших  производителей  компьютерных запоминающих устройств,  включая накопители на жестких дисках и ленте.  В 1996  г.  Quantum  была  вторым  крупным  производителем  дисков для серверов,  производя более 6 млн. дисков.  В  1996 г.  компания была также самым  большим  производителем,  продающим  накопители на жестких  дисках  для  персональных  компьютеров,  реализуя  их  более 25 млн.  У нее насчитывалось 23  подразделения по всему миру,  имеющих  предприятия,  поставщиков  и  клиентов  по  всей  Северной  и Южной Америке, Азии и  Европе. Компьютерные  запоминающие  устройства  —  циклический  бизнес с жесткой конкуренцией. В 1986 г. во всем мире было 350 производителей  дисковых  накопителей.  Однако  десять  лет  спустя  в  США остались  только  четыре  основные  фирмы,  производящие  дисковые *  Материал  данного  примера  был  переписан,  реорганизован,  сокращен  и объединен  на  основании  материала  следующих  источников:  Data  Warehousing Institute,  «BP 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.oracle.com/),  1996;  L  Radosevich,  «Quantum's  Leap,»  CIO Magazine,  February  15,1997. (прим.  автора).

187

ERP СИСТЕМЫ

накопители,  включая Seagate,  IBM, Western  Digital  и Quantum.  Конкуренция на рынке остается жесткой;  как заметил Делевати: Дисковые накопители стали  выгодным делом. Дисковые накопители компании Quantum известны своим качеством, мы продаем надежные дисковые накопители с высокими функциональными возможностями, скоростью и производительностью. Но клиенты всегда хотят чего-то с большими возможностями, более быстрым доступом и по менее высокой цене. Нам нужно быть в этом среди первых. Хотя компании Seagate и IBM  проектируют,  производят,  собирают,  распространяют  и  продают  свои  накопители  самостоятельно, компания Western  Digital  производит свои  накопители  в  сотрудничестве с другими фирмами. Quantum отличалась от других крупных производителей тем,  что производство было выведено за рамки компании, и компания занималась сбытом и маркетингом.

Бизнес-стратегия Quantum В то  время  как дисковые  накопители  пользовались все большим спросом,  стратегия Quantum заключалась в том,  чтобы сделать своим  конкурентным  преимуществом  работу  с  клиентами.  Как  сказал Делевати:  «Наша  бизнес-модель  ориентирована  на  наших  клиентов. Наши  отношения  с  клиентами  стоят  на  первом  месте  —  они  важнее технологии,  ценовых характеристик и  конструктива».

Информационные системы Quantum Quantum  была  ограничена  в  своих  возможностях  обслуживать клиентов.  В  ней  использовались девять  различных традиционных систем,  которые  поддерживали  работу ее  бизнес-единиц,  но  не обеспечивали им доступ к информации других бизнес-единиц.  В  результате  бизнес-единицы  компании  функционировали  наполовину  автономно, что затрудняло координацию при обслуживании клиентов. Весной  1994  г.  проблемы  информационных  систем  компании Quantum  были типичными  проблемами традиционных систем,  на которых  они  базировались.  Система  материального  планирования (MRP)  AskManMan  хранила  деловые  операции  каждого  подразделения  в  БД отдельных функциональных  и  бизнес-единиц.  Так как  БД  не могли  обмениваться  информацией,  эта  информация  объединялась вручную.  Поэтому процесс сбора факсов,  электронной почты и текстовой  информации  для  MRP  занимал  четыре  дня.  Закрытие  бухгалтерских книг занимало, по меньшей мере, 17 дней. Запасы, дебитор-

188

ЧАСТЬ ТРЕТЬЯ.  ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

екая и кредиторская задолженность — все это требовало сбора и обработки для отчетности. Даже  внутри  компании  информация  о  заказах  была  ограничена. Наличие запасов  не  могло  быть  подтверждено,  и доставка  могла занять  несколько дней  или  недель.  Чтобы  обработать заказ,  нужно было  собрать  информацию  из  множества  точек дистрибуции  по  всему миру.  На это также могло уйти несколько дней или недель.  К сожалению, если доставка занимала слишком много времени, заказы могли быть аннулированы.  Как сказал  Марк Джексон,  вице-президент компании:  «Наша работа была  ...  ниже  всяких норм». Ситуация усложнилась, когда в октябре 1994 г. Quantum приобрела  бизнес  систем  хранения  информации  компании  Digital  Equipment Corporation  (DEC).  Эта  компания  имела  финансовую  систему  собственной разработки наряду с другой традиционной системой MRP под названием  Maxcim,  разработанной  компанией  Computer  Associates. Кроме  того,  DEC  имела  несколько  различных  традиционных  систем, которые не могли взаимодействовать друг с другом. В результате менеджеры и сотрудники отдела продаж компании DEC не могли вовремя получать информацию в  масштабах всего предприятия.  Кроме того,  при  приобретении  удвоилось  число  объектов  системы  компании Quantum (например, списки продукции, номера поставщиков и клиентов). Наконец, после приобретения DEC число служащих и процессов, используемых Quantum,  также примерно удвоилось. Для  реализации  стратегии  обслуживания  клиентов  компании Quantum необходимо было предоставить возможность персоналу отдела продаж принимать и подтверждать заказы в реальном времени. Эти задачи требовали  возможности оценки текущих запасов и  резервирования заказа для клиента в  реальном  времени.  Возможность подтвердить и распределить запасы была названа возможностью «доступно по обещанию» («available to promise», ATP). Традиционные системы не имели такой возможности.  В отличие от традиционных систем, АТР могло быть  обеспечено  только  множеством  географически  распределенных подразделений и множеством модулей. То есть, АТР могло быть использовано только при  наличии достаточной  инфраструктуры  ERP.

ERP-проект компании Quantum В  1993 г. Quantum признала наличие этих проблем со своими системами.  В  результате в апреле  1993 г. ее подразделение информационных систем  начало  рассылать запросы с целью получения пред-

189

ERP СИСТЕМЫ

ложений по системе предприятия, которая отвечала бы нуждам компании.  В марте  1994 г.  Quantum  выбрала для оказания ей  помощи  в преодолении проблем существующих у нее информационных систем компании Oracle, Hewlett-Packard и Price Waterhouse,

Проектная команда Quantum Проектная  команда  Quantum  с  самого  начала  имела  поддержку  топ-менеджмента.  Как  сказал  Джексон:  «Чтобы  преуспеть, необходимо  потратить  деньги  и  позаботиться  о  деталях»,  В  апреле  1994  г.  Quantum  назначила  членов  проектной  команды  и  назвала  проект  «WARP»  (worldwide  ask  replacement  system  —  запрос замены  системы  по  всему  миру).  Ответственным  за  проект  был назначен  Майкл  Браун,  ставший  позже  СЕО  компании.  Под  его руководством  в  течение  лета  1994  г.  Quantum  создала  три  основные  проектные  команды.  Во-первых,  в  руководящий  комитет, возглавляемый  Брауном,  входили  вице-президенты  по  финансам, информационным  системам,  материально-техническому  снабжению,  производству,  закупкам  и  продажам,  а  также  представители компании  Price  Waterhouse.  Во-вторых,  была  образована  основная  команда,  в  которую  вошли  16  менеджеров  из  нескольких подразделений  и  бизнес-единиц  компании.  В  третьих,  была сформирована  проектная  команда,  состоящая  из  100  человек,  в которую  входили  сотрудники  подразделения  информационных  систем  и  по  несколько  ведущих  представителей  каждой  бизнесединицы.  Члены  последних  двух  проектных  групп  были  освобождены  от  своих  повседневных  обязанностей  и  полностью  задействованы  в  проекте.  Для  разработки  бизнес-процессов  были  организованы  межфункциональные  команды.  На  время  работы  над проектом  члены  групп  были  размещены  в  специальном  месте.

Выбор системы планирования ресурсов предприятий После  того,  как  команды  были  созданы,  был  проведен  анализ  существующих  процессов.  Используя  игровые  модели  и  другие  методы,  члены  команд  проанализировали  и  улучшили  бизнес-процессы.  Исходя  из  этих  новых  процессов,  были  установлены  требования  к  новой  системе.  После  рассмотрения  различных пакетов  программ,  включая  SAP  R/3,  Quantum  решила  внедрить БД  Oracle  7,  а  также  финансовые  и  производственные  модули Oracle.  Делевати  отметил,  что  приложения  Oracle  были  выбраны потому,  что  только  они  могли  обеспечить  возможность  реализации АТР.

190

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ ERP СИСТЕМ

Установка даты внедрения После  выбора Oracle Applications  команды  наняли  дополнительное количество консультантов из Price Waterhouse и Oracle.  Были запущены пилотные проекты. В конечном итоге, команды проекта WARP наметили внедрение на лето 1995 г.

Проблемы при внедрении Проблемы возникли практически сразу. Приобретение компании DEC  замедлило  внедрение.  Приобретение  подразделения  жестких дисков DEC усложнило проектирование и внедрение WARP. Согласно Делевати:  «Сложность  и  размеры  проекта увеличились в  четыре  раза». Имело место дублирование систем, процессов и объектов. Кроме того, проектную команду попросили интегрировать новое приобретение в Quantum. Соответственно, пока шла работа над новым приобретением,  проект WARP был  приостановлен натри месяца. В январе  1995 г.  проектная  команда была собрана снова.  Чтобы отразить  расширение  продуктовой  линейки  компании  с  учетом  дополнительных  объектов  и  процессов,  ей  было  необходимо  переделать свою изначальную работу.  В связи с увеличившимся масштабом и из-за необходимости повторного выполнения уже сделанной работы руководящий комитет увеличил финансирование.

Поэтапное  внедрение  против  внедрения  «сразу» Основным  решением,  которое предстояло принять менеджменту,  было —  использовать  поэтапное  внедрение  или  внедрение  «сразу». Решение повлияло бы на разработку, тестирование и, в конечном итоге, на успешность внедрения. При поэтапном внедрении компания обычно внедряет по одному модулю.  В  некоторых случаях  внедряются  по одному приложению  в одном  подразделении.  При  использовании  этого  метода  на  время внедрения ERP системы должны быть созданы временные интерфейсы  между  новыми  модулям  ERP  и  существующими  традиционными системами. При  внедрении  «сразу» фирма внедряет полный  набор  ERP-приложений  одновременно  во  всех  подразделениях.  Для  Quantum  использование этого метода означало бы внедрение 17 модулей Oracle в 23 подразделениях по всему миру фактически одновременно. Возникли споры по поводу того,  какой  метод выбрать.  С одной стороны,  Делевати  заявлял:  «Поэтапное  внедрение  —  более  дли-

191

ERP  СИСТЕМЫ

тельное  и  более  рискованное,  так  как  будут  задействованы  не  все специалисты,  и  действия  не  будут  скоординированы».  По  поводу сложности поэтапного внедрения Бобби Кэмерон, старший аналитик из  Forrester Research сказал;  «Если  компания  имеет горизонтальную организацию,  которая  не управляется жестко,  то очень трудно поддерживать проект на протяжении поэтапного внедрения». Однако Кэмерон  также  отметил,  что  большинство  крупных  фирм  используют одну из  версий  поэтапного  внедрения  и что  небольшое число  крупных фирм  используют внедрение  «сразу»: Это слишком сложно — особенно для крупных компаний — проводить крупный проект,... и риск, сточки зрения проектного менеджмента, высок... Огромные проекты одновременного внедрения достаточно сложны,  и большинство рассматривает небольшие — шаг за шагом — внедрения. (Radosevich 1997)

Вопросы 1.  2. 

3.  4.  5. 

Каким  требованиям  компании  Quantum  не  удовлетворяли  существующие у нее системы? Как Quantum должна была выбирать объекты  и процессы для своей  ERP системы, особенно после того, как приобрела компанию DEC, и произошло дублирование бизнес-процессов? Каковы  достоинства  и  недостатки  поэтапного  внедрения  и  внедрения «сразу»? Какой  метод  —  поэтапный  или  «сразу»  —  должна  использовать Quantum?  Почему? Как вы  считаете,  какие фирмы  будут использовать  метод «сразу»,  а  какие предпочтут поэтапный метод?

ПРИЛОЖЕНИЕ  11-2 Quantum II: внедрение «сразу» При  внедрении  программного  приложения  Oracle  Quantum  решила  использовать метод «сразу».  Как сказал  вице-президент  Марк Джексон:  «Если бы  мы  выбрали  поэтапный  метод,  мы  не смогли бы использовать АТР до полного внедрения системы. Нам пришлось делать внедрение «сразу».

192

ЧАСТЬ ТРЕТЬЯ.  ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

Тестирование  при  внедрении  «сразу» Системная тестовая аттестация № 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.  Эта новая  версия  требовала  множества  качественно  новых  настроек  и имела  сотни  новых  реляционных таблиц  БД,  требующих  конфигурирования. Несмотря  на наличие  плана всестороннего тестирования,  некоторые аспекты тестирования остались незамеченными. Хотя отдель-

193

ERP  СИСТЕМЫ

ные части проекта успешно прошли проверку, не была протестирована взаимозависимость  различных частей  системы.  Как заметил Делевати:  «Для  них было потрясением,  что,  хотя части системы  по отдельности работали, они не могли работать вместе». Чтобы подготовиться ко второму тесту, Делевати разработал организационную схему для  выявления  проблемных областей.  Был  составлен  подробный  список задач  проекта WARP  и  назначен  ответственный за каждую задачу. Среди категорий задач были бизнес-функциональность,  производительность  системы,  преобразование  данных, готовность информационных систем, обучение, документация и готовность отдельных подразделений. В рамках каждой задачи могли быть  сотни  подзадач.  Каждая  подзадача  была  обозначена  цветом, обозначающим достигнутую стадию готовности: •  зеленый =  «готово»; •  желтый  =  «требует доработки»; •  красный = «еще не готово». Когда подзадачи были обозначены цветами, команды смогли акцентировать внимание на задачах, обозначенных красным цветом.

Системная тестовая аттестация № 2 С каждым днем  все большее число задач обозначались зеленым цветом.  К началу декабря все задачи, ранее обозначенные красным, перешли  в  разряд «зеленых»  или  «желтых».  При  этом  была очевидна важность успеха повторной системной тестовой аттестации. Как сказал Делевати: Если бы вторая системная тестовая аттестация в мировых масштабах прошла неудачно, настрой команды упал бы. Она должна была стать успешной. Системная тестовая аттестация  №  2  проводилась с  11  декабря 1995 г. по 8 января 1996 г. Для участия в тестировании системы в главный офис корпорации прилетели пользователи со всего мира. Хотя  системная  тестовая  аттестация  №  2  прошла хорошо,  тесты выявили  несколько  областей,  требующих  дальнейшей  работы.  В  результате Quantum назначила итоговое тестирование на февраль 1996 г. В  рамках этого тестирования  «желтыми»  из  «зеленых» стали только те задачи, которые требовали дополнительного внимания при реализации WARP. Например, в ходе тестирования сеть в Пенанге (Малайзия) оказалась близка  к перегрузке.  К сожалению,  чтобы увеличить  пропускную способность этой сети, понадобилось 90 дней. Чтобы избежать задер-

194

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ ERP СИСТЕМ

жек  во  внедрении,  команда закрыла  персоналу в  Пенанге доступ  в  Интернет до момента увеличения пропускной способности сети — вся ширина  полосы  была отдана  под приложения Oracle.

Обучение Во время внедрения и тестирования системы Quantum финансировала  обучение  пользователей.  24-месячный  график  внедрения предусматривал  шестинедельное  обучение  в  мировых  масштабах. На время обучения, длящегося от двух до четырех недель,  служащие были освобождены от работы. Джексон заметил:  «Отношение к обучению было очень серьезным,  и менеджерам на местах не разрешалось  отвлекать  служащих  от  обучения,  независимо  от  возникавших проблем в бизнесе».

Внедрение «сразу» К 26 апреля 1996 г. большинство проблем проекта WARP было решено.  В  17.00  по среднетихоокеанскому времени  переход  начался. Все записи были конвертированы и переведены в приложения Oracle. 3 мая был выполнен «моментальный снимок» данных и проведены некоторые операции. Вскоре после этого 100 членов проектной команды  вошли  в систему для  работы с  некоторыми образцовыми данными. Система работала.  Пришло время внедрения «сразу». 5 мая Джексон запустил систему для реальной работы. Старшие менеджеры  и  проектная  команда  наблюдали  за тем,  как  к  системе подключаются  пользователи  со  всего  мира.  Как заметил Делевати: «Это был  волнующий  момент,  все были  полны энтузиазма.  Свое домашнее задание мы  выполнили.  Мы были уверены,  что система будет работать».  Кб мая 1996 г. Quantum конвертировала дебиторские задолженности на сумму более 1  млрд. долларов и заказы на сумму 1,6 млрд. долларов, открытые во время внедрения. Система компании Quantum,  насчитывающая  более  1  300  пользователей  по  всему миру,  стала самой большой  распределенной системой  приложений Oracle,  внедренной с использованием метода «сразу». Делевати отметил, что бизнес, как мы и предполагали, остановился. В течение восьми календарных дней  мы не могли  размещать заказы,  не могли получать материалы,  не могли осуществлять перевозки продукции.  Мы даже не могли перевести деньги.

195

ERP СИСТЕМЫ

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

Функциональные возможности приложений Oracle В  конечном  счете,  система  задействовала  девять  серверов  HP для поддержки более 40 000 таблиц реляционных БД.  В Quantum приложения Oracle используются в основном для управления запасами и для  финансовых  операций.  Установка  Oracle  позволила  интегрировать в одной системе  информацию  и о  наличии запасов,  и о поставках.  Таким  образом,  наличие  запасов  и  сроки  поставок  могли  быть подтверждены  буквально  в  считанные  минуты. Внедрение  системы  имело  и  дополнительные  преимущества. Как сказал Делевати: Одно из самых очевидных преимуществ — это то, что все наши заказы,  все наши запасы  и все  наши финансы  консолидированы  и централизованы. Это огромное конкурентное преимущество. До новой системы  на закрытие бухгалтерских книг уходило,  по меньшей мере, 17 дней. В первый месяц работы новой системы... мы закрыли книги за девять дней. А в конце первого квартала на это потребовалось только 11 дней. Делевати также отметил: «В плане стратегии мы можем предугадывать,  когда  следует  сворачивать  производство  одних  продуктов  и наращивать его для других и упреждать желания клиентов при планировании жизненного цикла. Это большое преимущество — управлять данными  в  реальном  времени  в  соответствии  с  маркетинговой  информацией».

Затраты  и  результаты По оценке  Марка Джексона  проект был столь же дорогим,  как  и разработка и создание новой предметно-производственной специализации.  Хотя  исследование  возврата  на  инвестиции  (ROI)  не  было проведено, для определения  меры успешности  внедрения,  Джексон

196

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ ERP СИСТЕМ

считал,  что  проект  внедрения  был  успешным,  и  комментировал  свое мнение следующим  образом: Мы могли бы рассчитать,  как сэкономить 10% расходов на проект,  что было бы значительной суммой,  но я думаю,  что это увеличило бы риск до неприемлемого уровня. Чтобы преуспеть, необходимо потратить деньги  и  позаботиться о деталях.

Вопросы 1.  2.  3. 

Каковы  некоторые другие  причины  выбора компанией  Quantum  метода внедрения «сразу»? Какие  факторы  способствовали  успешности  внедрения  компании Quantum? Что вы думаете о методе тестирования,  использованном Делевати?

ПРИЛОЖЕНИЕ 11-3

Quantum III: сотрудничество и конкуренция 24  июня  1996  г.  подразделение  прикладных  систем  корпорации  Oracle  объявило,  что  «несколько  компаний,  включая  Silicon Graphics,  Inc.  и  корпорацию  Quantum,  работали  с  Oracle Applications  в  течение  квартала,  причем  обе  эти  компании  успешно  провели  крупномасштабные  внедрения».  Кроме  того,  в  это  же время  подразделение  прикладных  систем  корпорации  Oracle  объявило,  что  «среди  новых  клиентов,  появившихся  за  этот  квартал ...  компания  Western  Digital  ...»

Вопросы 1.  Что  вы  думаете  по  поводу выбора  компанией Western  Digital системы  Oracle Applications?  Как вы  считаете,  что думает  компания Quantum  по поводу выбора компанией Western  Digital этой  ERP системы? 2.  Как  вы  считаете,  какие  возможности  системы  выберет  для внедрения Western  Digital?

197

ERP  СИСТЕМЫ

12 ЖИЗНЬ  ПОСЛЕ ЗАПУСКА

После завершения внедрения ERP системы забывать о ней,  потому что «дело сделано», еще не время. В это время организация вступает в стабилизационный период,  в течение которого она обычно переживает спад в производительности. Значит, чтобы смягчить этот отрицательный эффект, фирмам необходимо много работать. Чтобы справиться  с  повседневными  проблемами,  связанными  с  ERP  системой, фирме  необходимо  организоваться,  а менеджменту определить,  что еще необходимо сделать,  и соответствует ли результат плану внедрения системы. Менеджмент также должен решить, какая модернизация, расширение  или  связи  могут или должны  быть  реализованы для  ERP системы. Наконец, фирме необходимо оценить успешность проекта.

Стабилизационный  период После запуска системы  начинается так называемый «стабилизационный период»,  продолжающийся обычно от трех до девяти месяцев.  В  течение  этого  периода,  как  заметил  директор  Benchmarking Partners:  «Большинство  компаний должны  быть готовы  к некоторому спаду в бизнесе и к тому,  что им придется с ним справляться» (Koch 1999).  Например,  в результате проведенного недавно исследования Deloitte Consulting выяснилось, что после запуска ERP систем, каждая четвертая фирма пережила некоторый спад в деятельности. В  стабилизационный  период  начинают  использоваться  все  те процессы, которые когда-то были просто планами. Новые ПО и процессы могут быть не знакомы пользователям. Соответственно, могут возникнуть  проблемы  с  качеством  и  объемом  работы,  и,  следовательно, система может не работать так,  как предполагалось.  Например, при обсуждении системы, которая была запущена в январе 1998 года, Коч (Koch 1999) заметил: Доставки не осуществлялись: клиенты получали не то количество или не ту продукцию, которые они называли. У служащих отдела работы с клиентами было столько вопросов по новой системе, что первые  несколько  недель  проектная  команда  потратила  большую часть времени,  решая  возникшие у них проблемы...  Только спустя пять месяцев, в мае ... компания решила проблемы со своими клиентами. Система не стабилизировалась до сентября.

198

ЧАСТЬ ТРЕТЬЯ.  ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

Таким образом, важно, чтобы пользователи прошли соответствующее обучение в нужное время. Знания, полученные в период слишком  раннего обучения,  могут быть утрачены,  но обучение,  проведенное слишком поздно, может оказаться запоздалым. В  стабилизационный  период  время  обработки  данных  и  ответа сети  могут  не  соответствовать  возможностям  внедренной  системы, форсируя осуществление изменений пропускной способности сети и обработки  данных.  Например,  когда  ERP  система  была  запущена  в компании  Cisco,  обнаружилось,  что  основная  проблема  снижения производительности состояла в масштабах оборудования и его архитектуре (Cotteleer, Austin, and Nolan  1998). Кто  решает  эти  проблемы?  В  рамках организации  первоначальная  команда  проекта  может  быть  наращена  с  целью  обеспечения поддержки  нужд  пользователей,  содействия  дополнительному  обучению  и  внесения  необходимых  изменений  в  систему.  Коч  (Koch 1999), цитируя члена проектной команды, говорит: «В начале проекта я  думала,  что  смогу  по  его  завершении  вернуться  в  свою  группу...». Вместо этого во время выполнения данной работы она стала в компании  сначала  неофициальным  помощником,  а затем  и  консультантом со стороны  SAP.

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

199

ERP СИСТЕМЫ

•  обслуживание  и  обновление документации  и  материалов  обучения; •  обслуживание и обновление  ПО. Кто  является  членами  этой  команды  поддержки  организации? Члены  первоначальной  проектной  команды  внедрения  ERP  могут быть  важными  игроками  в  осуществлении  повседневных  операций. Следовательно, важно удержать членов проектной команды, которые имеют  (пользующуюся  высоким  спросом)  сноровку,  необходимую для  выполнения  повседневных  операций  в  ERP  системе.  В  целом, члены  команды проекта имеют ценные знания,  которые необходимо сохранить, и сделать это можно, только удержав их. Соответственно, фирмам  нужно  уведомить  членов  проектной  команды  по  поводу  их карьерных возможностей, которые позволят им использовать их знания в фирме. Проведенное недавно исследование (Stedman 1998) выявило, что различные программные пакеты  ERP требуют различных затрат на их использование.  При  исследовании  50  фирм,  проведенном  МЕТА group,  выяснилось, что полная стоимость использования системы за два года (в процентах от годового дохода) составила от 0,4% для  ПО фирмы Lawson, до 0,67% для SAP и до 1,1% для BAAN. Конечно, экстраполяция на основании таких исследований может быть ограничена многими промежуточными факторами, такими как, например, размер фирмы.  Например,  система  компании  Lawson  обычно  внедряется  в менее крупных фирмах, в то время как BANN имеет репутацию системы, внедряемой в основном более крупными фирмами.

Определение того, что еще нужно сделать или переделать Установить,  что должно быть сделано (или переделано)  во внедренной системе, можно путем оценки преобразования данных, определения того, какие новые «узкие места» возникли в процессах с момента внедрения системы (например,  в течение стабилизационного периода) и оценки достаточности обучения и документации.

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

200

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

менении данных имеет ряд источников, таких как существование новых полей и разработка новых МОПов (списков поставщиков, таблиц счетов и т. д.). Во многих случаях качество преобразования данных (и вытекающие отсюда проблемы) может быть оценено только со временем. Накопленные данные  необходимо  исследовать  на  «смысл».  Например, может оказаться, что происходит накопление запасов, падение сборов, и начинают происходить простои в работе. Но эти изменения на самом деле могут говорить о проблемах, возникающих из-за неадекватного преобразования данных:  неверных номеров подразделений, поставщиков или инвентарных номеров. Решение  потенциальных  проблем,  связанных с  преобразованием данных,  обычно требует ряда действий,  включая следующие.  Вопервых, где можно, следует привести в соответствие данные в их источниках для традиционной системы и ERP системы,  поставив такие вопросы, как: Совпадают ли инвентарные номера? Если нет, то почему?  Совпадают ли  номера товаров?  Если  нет,  то почему? Совпадают ли  номера поставщиков  (клиентов  и т.  д.)?  Если  нет,  то почему?  Вовторых,  нужно осуществить отображение данных из одной  БД в другую,  чтобы  убедиться,  что  включены  все данные.  Отображение данных может выявить новые  и  пропущенные номера как товаров, так и поставщиков,  и  клиентов.  Запасы  должны  быть  эквивалентны.  Без этих мероприятий нет гарантии того, что при преобразовании данных не были  перепутаны  какие-то  их разновидности  или  что  все данные учтены.

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

201

ERP  СИСТЕМЫ

Как определить «узкие места»? Один из подходов — прислушаться  к клиентам  и партнерам.  На что они жалуются? Установить причину  этого  недовольства.  К  сожалению,  недовольство  возникнет  не сразу. Другой подход — сидеть и ждать, пока вопросы и запросы ресурсов  не  завалят  справочный  стол.  Этот  подход  также  может  оказаться слишком запаздывающим. Для  обнаружения  «узких  мест»  можно  использовать  два  других подхода:  внутренний  анализ  данных  ERP  системы  и  организационный анализ.  Внутренний анализ ERP системы базируется на исследовании  ее  данных.  Для  выявления  возникающих  и  повторяющихся проблем могут быть проанализированы сообщения о простоях и операционные данные. С другой стороны, до того, как они превратятся в главные  проблемы,  некоторые  затруднения  могут  быть  выявлены  из бесед с теми,  кто использует систему.

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

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

202

ЧАСТЬ ТРЕТЬЯ.  ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

Компромиссы при внедрении Компромиссы при внедрении — это отклонения внедрения от запланированного в основном в целях экономии времени или денег. Зачастую в стремлении  видеть систему установленной  идут на компромиссы. После того, как система внедрена, важно выяснить, что необходимо сделать или переделать в результате этих компромиссов.  Например, как заметил старший менеджер по системам корпоративного учета  Federal  Express:  «Во  время  реализации  проекта существуют проблемы со временем или возможностями,  которые заставляют вас говорить:  «Мы сделаем это позже» (Koch  1999). Каковы  последствия  компромиссов  при  внедрении?  Установка ERP  системы  в  этом  случае,  конечно,  позволяет  сэкономить  время или деньги по сравнению с возможными издержками при отсутствии компромиссов.  Однако, так как внедрение не было полным,  система и процессы не будут функционировать в полной мере так, как предполагалось. Таким образом, компромиссы при внедрении повлияют на оценку.  В некоторых случаях они могут,  в конечном итоге,  привести к компромиссам в обязательствах, как, например, когда переход к ERP системе осуществлялся  в  целях  изменения  ключевых  процессов  или для  привнесения  ключевых  изменений,  а  именно  здесь  пошли  на компромисс. Один  из  компромиссов  при  внедрении  —  это  временное принесение  в  жертву  безопасности.  Например,  парольная  защита может  быть  сначала  установлена  на  групповом,  а  не  на  индивидуальном  уровне.  Другой  частой  областью  компромиссов  при внедрении  является  ввод/вывод  данных.  Например,  после  внедрения  ERP  системы  компанией  Geneva  Steel  было  обнаружено, что  не  выполняются  требования  пользователей  по  созданию  отчетов.  Для  соответствия  этим  требованиям  было  установлено хранилище  данных,  которое  использовалось  для  создания  отчетов  в  соответствии  с  запросами  пользователей.  Это  показывает,

203

ERP  СИСТЕМЫ

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

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

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

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

204

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

Модернизация В  некоторых  случаях для  внедрения  дополнительных характеристик должен  быть  осуществлен  переход  на другие  версии  системы. Например,  фирма  ABB  поставила  в  известность  каждую  из  тысячи своих  компаний  о  том,  что  они  должны  внедрить  функциональностоимостной анализ — возможность,  которую ABB Industries решила реализовать  с  помощью  SAP.  Однако  после  внедрения  версии  3.0 системы  R/3  обнаружилось,  что  для  полного  внедрения  этого  вида анализа требуется более поздняя версия ERP системы. То есть,  возможность внедрения фирмой  необходимой характеристики — функционально-стоимостного  анализа  —  зависела  от  внедрения  новой версии SAP.

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

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

205

ERP  СИСТЕМЫ

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

Оценка  успеха По окончании  стабилизационного  периода фирма может начать процесс оценки успешности проекта. Это требует определения того, когда должна быть выполнена такая оценка и как именно должна быть оценена успешность,  — например,  с помощью анализа затраты-выгоды,  некоего  анализа,  основанного  на  критериях,  использованных при  решении  о  внедрении  ERP  системы,  или  при  помощи  метода Balanced Scorecard (BSC)*. Таблица  1 2 . 1 .  Реальные  и  предполагаемые  факторы  проекта Каковы были реальные выгоды в процентах от ожидаемых: Продолжительность  Стоимость  Выгоды   200%

0,0 25,0 27,5 25,0 3,0 16,5 3,0

0,0 13,5 43,0 24,5 8,0 2,5 8,0

6,0 65,0 8,5 14,5 0,0 3,0 3,0

Примечание:  Выгоды  являются  средними  процентными  соотношениями данных  1998 и  1999 гг.,  рассмотренных в (Austin and Cotteleer  1999). В  некоторых случаях  из-за  округления  сумма  чисел  в  некоторых  колонках неравна 100%.

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

206

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

Определение продолжительности, затрат и выгод Проектный менеджмент требует мониторинга продолжительности проекта, затрат и выгод от внедрения (например, бизнес-преимуществ)  ERP  системы.  Было  множество  сообщений  о  проблемах  со своевременностью  и  «рентабельностью»  внедрения  ERP  систем. Проведенное  недавно  исследование  (Austin  and  Cotteleer  1999),  результаты которого представлены в таблице 12.1, выявило, что выгоды от  реализации  проектов  внедрения  ERP часто  не оправдывали  ожиданий, при том, что затраты часто превышали ожидаемые. Вероятно, это можно объяснить тем, что с целью продажи систем топ-менеджменту  затраты  могли  систематически  преуменьшаться,  а  потенциальные  результаты  переоцениваться. Хотя продолжительность проекта была иногда меньше, чем предполагалось,  чаще она была больше предполагаемой,  причем в некоторых случаях больше  почти  вдвое.  Таким  образом,  не удивительно, что внедрения ERP систем имеют репутацию превышающих бюджет и запланированное время (см., например, March and Garvin 1996). Однако,  возможно,  самый  интересный  результат  исследования  —  это то,  что только 44% фирм формально  отследили  полученные  выгоды.  Кроме  плохого  проектного  менеджмента,  это  можно объяснить и другими причинами. Во-первых, общеизвестно, что выгоды определить сложнее, чем затраты, так как часто они менее материальны.  Во-вторых,  может не существовать способов  их определения,  особенно  когда  проект  был  обоснован  технологическими, стратегическими  или  конкурентными  доводами,  и,  следовательно, конкретные выгоды не могут быть выделены  .  В-третьих,  фирмы могут рассматривать  внедрение как  неокупаемое капиталовложение  и, следовательно, не видят пользы от оценки выгод.

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

207

ERP  СИСТЕМЫ

сервер,  решить  «Проблему  2000-го  года»  или  ответить  на  вызов со  стороны  конкурентов,  не  обеспечивают  определенность  оценки.  Как  только  принято  решение  о  внедрении  ERP  системы,  и, таким  образом,  вопросы  «Проблемы  2000-го  года»  и  ПО,  работающего  в  среде  клиент-сервер,  решены,  оценить  мало  что  можно. Основание  легко  «ответить  на  вызовы  конкурентов»  может  быть слишком  аморфным,  и  здесь  достаточно  просто  решить  установить  ту  же  ERP  систему,  что  и  конкуренты.  Это  может  стать  важным  для  сбора  более  детальных  метрик  производительности,  таких  как,  например,  что  значит  «соответствовать»  конкуренции, чтобы  зафиксировать  в  проекте  большие  специфику  и  обратную связь. Стратегические резоны и основания со стороны бизнес-процессов  могут  способствовать  более  определенной  оценке.  Например, основанием  могло  послужить  улучшение  управления  запасами.  С улучшением  управления  запасами  могут  быть  ассоциированы  конкретные измерения сырья, полуфабрикатов и готовых товаров. Уровни запасов,  запасов в процентах к продажам  или движение запасов могут  быть  использованы  как  конкретные  критерии  оценки  улучшений. Приведем другой пример: резоном послужило улучшение перевозок и материально-технического  снабжения.  С  улучшением  перевозок  и  материально-технического  снабжения  могут  быть  связаны конкретные показатели затрат на содержание складов и на перевозки.  Например,  предполагаемое  сокращение  затрат  на  содержание складов  благодаря  внедрению  ERP  системы  может  быть  оценено  в процентах от продаж. Конкретные  показатели  позволяют  детализировать  исследование в процессе оценки.  Если измерения выявляют меньшие улучшения,  чем  предполагалось,  фирмам  необходимо  выяснить  причину  и определить, возможны ли дальнейшие улучшения. Фирма также может решить,  как настроить  ERP систему,  чтобы ее внедрение позволило достигнуть конкретных целей.

Независимые показатели или взвешенный набор показателей При  любой  оценке  внедрения  ERP  систем  необходимо  определить,  использовать  для  оценки  проекта  независимые  показатели  или  набор  показателей.  Если  используются  независимые  показатели,  и  все  они  достигнуты,  то  результаты  оценки  понятны. Однако  если  одна  или  несколько  целей  не  достигнуты,  то  возникает  некоторый  вопрос  относительно  результатов  оценки.  Напри-

208

ЧАСТЬ ТРЕТЬЯ.  ЖИЗНЕННЫЙ  ЦИКЛ  ERP СИСТЕМ

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

Система сбалансированных показателей Данный  метод  оценки  функционирования  организаций  был опубликован  в  работах  Каплана  и  Нортона  (Kaplan  and  Norton 1992)  и  Каплана  и  Аткинсона  (Kaplan  and  Atkinson  1998).  Система сбалансированных  показателей  отражает  различные  цели  фирмы с  различных  точек  зрения,  таких  как  финансы,  клиенты,  обучение и  рост,  а  также  внутренние  бизнес-процессы.  В  процессе  оценки используются  различные  показатели,  а  не  один  показатель  или один  тип  показателей. Метод  использования  различных  точек  зрения  и  множества  показателей  может быть  распространен  на оценку внедрения  ERP  систем.  В  системе  сбалансированных  показателей  для  ERP  системы могло бы быть использовано каждое из четырех основных бизнес-оснований (технология, бизнес-процесс, стратегия и конкуренция), использованных при принятии решения о внедрении ERP системы, и таким  образом  определен  набор  перспектив  и  показателей,  которые будут зависеть от конкретной компании  и ее резонов внедрения  ERP системы.

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

209

ERP  СИСТЕМЫ

Резюме После  запуска  ERP  системы  предстоит  еще  многое  сделать. Команда  внедрения  должна  провести  фирму  через  стабилизационный период. Кроме того, необходима организация для повседневного  поддержания  работы  системы.  После  запуска  системы  фирма должна  определить,  что  необходимо  сделать  и  переделать.  Например,  преобразование данных,  компромиссы, допущенные при  внедрении,  «узкие места» в процессах и документация — все это следует оценить,  чтобы  гарантировать,  что  все  соответствует  нуждам.  Для определения пределов компромиссов при внедрении фирмам необходимо сравнить свои планы с реальными результатами. Они должны также  рассмотреть,  какую  модернизацию  системы  им  следует  осуществить,  какие связи с традиционными системами необходимо реализовать,  и должны ли быть сделаны  какие-нибудь расширения  ERP системы, и если да, то какие. Фирмам  необходимо  оценить  успешность  внедрения.  Однако одно исследование показало,  что анализ  выгод осуществляют только 44% фирм.  Отсутствие анализа выгод может быть следствием плохого проектного менеджмента, трудности оценки  результатов,  оснований,  использованных для выбора или оценки внедрения ERP системы или  рассмотрения  проекта  как  неокупаемого  капиталовложения.  В тех  случаях,  когда  выгоды  анализируются,  может  быть  использован продолжительный анализ  затрат  и  выгод.  Могут также  быть  использованы другие средства оценки, базирующиеся,  возможно, на резонах,  использованных при  принятии решения о внедрении ERP системы,  или какие-то иные.  В любом случае, так как выгоды требуют времени для  их  проявления  и  возможности  измерения,  оценку следует начинать не раньше,  чем через год после запуска системы. Наконец,  многие фирмы  не  выделяют достаточных бюджетов  на рассмотренные  в данной  главе  задачи,  которые  необходимо  реализовать  после  внедрения  системы.  Для  проведения  проектного  менеджмента в течение всего ее жизненного цикла необходим  адекватный бюджет, чтобы гарантировать наличие ресурсов в течение реализации всего проекта.

Литература Austin,  R.,  and  Cotteleer,  M.  (1999).  «Current  Issues  in  IT:  Enterprise  Resource Planning».  Unpublished presentation, October.

210

ЧАСТЬ ТРЕТЬЯ. ЖИЗНЕННЫЙ ЦИКЛ ERP СИСТЕМ

Cotteleer,  M.,  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, R., and Norton, D. (1992). «The Balanced Scorecard: Measures That Drive Performance».  Harvard  Business  Review,  January/February. Koch, С (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. Stedman,  G.  (1998).  «ERP  User Interfaces  Drive Workers  Nuts».  Computerworld, November 2, pp.  1, 24.

ПРИЛОЖЕНИЕ  12-1 Изучение случая компании XYZ* Как следует оценить ERP-проект? Наша  фирма  выработала  и  распространила  следующие  показатели.  Эти  показатели были выдвинуты как желаемые примерно через год после запуска системы.

Запасы •  Сокращение  имеющегося  в  наличии  сырья  на  срок  менее 20  дней. •  Сокращение продукции в незавершенном производстве на 40%. • Повышение оборачиваемости готовых товаров с 9 до 12 раз в год.

Общее администрирование •  Публикация  финансовых  материалов  в течение  6  рабочих дней (в настоящее время 24 дня). •  Повышение уровня обслуживания клиентов до 99%,  а своевременности доставки до 90% (в настоящее время 97% и 70%, соответственно). •  Повышение  эффективности  производства,  продаж,  финансов, закупок, техники и информационных систем на 10%.

*  Название  фирмы  вымышленное  и  некоторые  цифры  были  изменены.  Информация  предоставлена  менеджером,  отчитывающимся  непосредственно  перед  вице-президентом  этой  средней  по  размеру фирмы (прим.  автора).

211

ERP  СИСТЕМЫ

Подразделение А •  Повышение валовой прибыли  на 6% от продаж.

Подразделение Б •  Повышение валовой прибыли на 2% от продаж. Я  обеспокоен тем,  что мне не ясно,  является это показателями или целями. Кроме того, внедрение не добавляет функциональности, которая  уже  номинально  не  присутствовала бы.  Поэтому буду  признателен вам за высказанные замечания по следующим вопросам. 1)  Что вы думаете по поводу этих метрик? 2)  Являются ли они показателями или целями? 3)  Если  это  цели,  подходят ли  они для  проекта  внедрения  ERP системы? 4)  Если это показатели, позволяют ли они оценить факторы, непосредственно относящиеся к внедрению? 5)  Представляют ли эти показатели (цели) по отдельности или все вместе разумные ожидания команды менеджмента относительно их ERP проекта? Если нет, то какие показатели или цели будут надлежащими?

ПРИЛОЖЕНИЕ 12-2 Список контрольных вопросов компании Deloitte Consulting для периода после внедрения ERP системы* Проекты  внедрения  ERP  систем  более  успешны,  если  имеется конкретный план действий на период после запуска системы. Задайте  себе  эти  вопросы  относительно  планов  после  внедрения,  чтобы понять, готовы ли вы и ваша команда. Если на какой-то из них ваш ответ  будет  отрицательным,  сделайте  шаги,  чтобы  как  можно  скорее перевести ответ на него из НЕТ в ДА.

Основы У вас есть план действий после внедрения?

Цели получения преимуществ •  Есть  ли  у  вас  перечень  бизнес-выгод  и  возможностей  от  использования ERP системы в бизнес-планах конкретных главных управляющих (CEO, CFO и т. д.)? * Данный  список контрольных  вопросов  представлен  в  Koch,  С.  (1999).  «The Most Important Team in  History.»  (CIO Magazine,  October  15),  где он  приписывается компании  Deloite  Consulting (прим.  автора).

212

ЧАСТЬ ТРЕТЬЯ.  ЖИЗНЕННЫЙ  ЦИКЛ  Н