Информационные технологии управления / Учебные пособия / ИТУ_Мастеров А.Г., Орлова

мог себе представить лет десять назад, что найдется сила, способная смести с главенствующих высот компании, подобные IBM, Digital Equipment и Wang?

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

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

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

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

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

61

роста этих компаний (который происходит не за счет приобретений и расширения глобального рынка) составляли не более половины процента.

Кроме того, тот факт, что производитель стремится отвечать запросам заказчиков, не обязательно свидетельствует о его возможности вводить новшества. Причина, как объяснил профессор бизнес-школы в Гарварде Клейтон Кристенсен, автор известной книги «Дилемма новатора» (The Innovator's Dilemma), а том, что удачливый производитель выпускает те продукты, которые необходимы потребителям именно сейчас. Хотя на первый взгляд это хорошо, слишком сильная ориентация на пользователей вынуждает производителей пренебрежительно или настороженно относиться к «разрушительным» технологиям, которые пока еще потребителей не интересуют.

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

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

Среди них, по словам еще одного профессора из Гарварда Марко Янсити, автора книги «Интеграция технологий» (Technology Integration), — ориентация на разработку прототипов. Янсити потратил десять лет на изучение методов, используемых компаниями, выпускающими аппаратное и программное обеспечение, для воплощения результатов исследований в реальных продуктах. Он пришел к выводу, что традиционная модель разработки ориентируется на спецификации. Это означает, что разрабатывающая компания анализирует требования к системе, пишет и утверждает спецификацию, а затем постепенно детализирует реализацию продукта. Такую модель еще называют каскадной или подходом «сверху вниз». С другой стороны, подход, ориентированный на создание прототипов, намного более адаптивен. В этом случае разработчик быстро создает прототип и затем совершенствует его.

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

62

добавил, что Yahoo и Microsoft могут служить хорошими примерами подобной практики.

К примеру, Джон Деваан, вице-президент Microsoft и руководитель подразделения приложений для настольных систем, более 14 лет проработавший в корпорации, подчеркнул, что Microsoft использует прототипный подход к исследованиям и разработке офисных приложений, чтобы обеспечить оптимальное взаимодействие Office 2000 с Web-серверами. Office 2000 — это пакет настольных деловых приложений, который должен быть выпущен в начале следующего года. Он позволит сохранять документы непосредственно на серверах Web в форматах HTML и XML.

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

Данный подход, как считает Деваан, представляет собой существенный сдвиг в методах работы Microsoft. Когда в начале этого десятилетия разрабатывался Excel 3.0, программисты просто придумывали новые возможности и встраивали их в электронные таблицы. Как таковой «процесс» проектирования просто отсутствовал.

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

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

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

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

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

63

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

Число запущенных в компании проектов зависит от ее размера и наличествующих ресурсов. Но общее эмпирическое правило состоит в том, что инженеры должны вести не более двух ключевых проектов одновременно.

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

— сказал Кристенсен. — Компания добилась этого благодаря максимальному сосредоточению усилий».

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

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

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

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

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

64

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

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

К примеру, системный интегратор — компания American Management Systems (AMS) имеет специальный центр перспективных технологий, где тестируются новые технологии, например XML, с тем, чтобы разработчики могли представить, как эти новшества могут использоваться для решения каждодневных бизнес-задач. «Большинство крупных компаний очень стараются протолкнуть перспективные технологии на рынок, но иногда прекрасные новшества губит слишком сырая реализация», — сказал Уинстон Чанг, руководитель центра перспективных технологий AMS и директор лаборатории технологий Internet и Web.

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

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

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

4.5. Из истории автоматизации методологий управления предприятия

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

Сергей Колесников, Computerworld Россия

65

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

Для решения задачи управления была разработана методология планирования материальных ресурсов предприятия — MRP (Material Requirements Planning), однако оказалось, что кроме методических трудностей здесь имеются и математические, которые полностью были решены только с приходом вычислительной техники. Использование этой методологии подразумевает, как правило, применение MPS «Master planning schedule» — старой и хорошо известной под названием «объемнокалендарное планирование», методологии, которая является базовой практически для всех планово — ориентированных методологий.

После этого достаточно быстро был реализован вариант планирования производственных ресурсов (мощностей) — CRP «Capacity Requirements Planning», методология которого принципиально была похожа на MRP, но речь шла о расчетах необходимых производственных мощностей, а не материалов и компонентов. Эта задача была существенно сложнее, поскольку требовала учета большого числа параметров, а окончательный расчет обязательно включал не только мощностной параметр, но и временную последовательность. Стандартная задача расчета производственных ресурсов «знает» об ограниченных мощностях обрабатывающих центров, но максимум, что она может сделать — это рассчитать «потребность» в рабочем времени для выполнения запланированной производственной программы при неограниченном горизонте планирования, либо показать превышения (недостаток) потребных мощностей при ограниченном. Если результат оказывался неудовлетворительным, то требовалось изменить производственную программу и повторить процесс сначала. Поскольку это весьма ресурсоемкая вычислительная задача, которая даже на современной технике может выполняться часами, то ясно как была нетехнологична эта процедура.

Объединение названных методологий дало задачу MRP «второго уровня» MRP II «Manufacturing Resource Planning» — интегрированную методологию планирования, включающую MRP\CRP. При использовании данной методологии обязательно подразумевается анализ финансовых результатов производственного плана, а также применение MPS и FRP

«Finance resource/requirements Planning» — планирование финансовых ресурсов, правда без их интеграции в «динамическую систему». (Часто пишется без добавления индекса II, так что в некоторых публикациях нужно ориентироваться по контексту, какая из методологий имеется ввиду.)

66

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

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

Модель одна — реализаций много

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

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

•интегрированное управление для заказного и мелкосерийного производства (машиностроение, автомобилестроение и др.);

•управление сложными финансово-сбытовыми и производственными структурами — холдинговое управление («финансовое управление» — финансово-промышленные группы, «логистические цепочки» и «управление распределенными потребностями» — крупные торгово-производственные компании).

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

67

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

•управление складским хозяйством (автоматизированные склады);

•управление «оперативным» контуром (интенсивной отгрузкой продукции);

•управление «глобальной» логистикой больших компаний и ряд других направлений.

Два последних направления лежат в основе методологий управления так называемыми компаниями типа FM-CG (fast moving consumer good — быстро движущиеся потребительские товары — напитки, сигареты, консервы

—это практически все «товары повседневного спроса», которые не производятся в мелком частном секторе, как хлеб, например).

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

Стратегическое

планирование

ERP

Обобщенное FRP планирование производства

MPS

MRP II

MRP		CRP

Цеховой

план

Рис. 1. Взаимосвязь систем планирования

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

68

Несмотря на то, что «чистых» решений, основанных на одном из таких подходов не существует, тем не менее, «истоки» очень сильно сказываются на возможностях и качественных характеристиках систем. Сегодня очевидны преимущества функционального подхода в области управления производством, типичными представителями которого являются решения от Ваап и Symix. Финансовый подход проповедует компания SAP в своем продукте R/3, действительно, это оказалось очень эффективно для управления бизнесом холдингового типа и чисто финансовых институтов.

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

Всущественной же степени он встречается только в «малых» системах

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

или Microsoft Outlook).

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

Часто можно услышать диалог заказчика с поставщиком решения примерно такого содержания: «но вы не можете решить нужные мне задачи, а делать так, как вы предлагаете — значит пользоваться кремниевым топором», — ответ поставщика: «да пожалуй, но чехол-то топора от Oracle, Microsoft, Sybase!». Самое поразительное, что стоимость таких решений, включающих запуск в промышленную эксплуатацию, иногда превышает стоимость внедрения SAP R/3, на сравнимых конфигурациях, при значительно более низкой функциональности (данный расчет ведется достаточно просто: общая окончательная стоимость проекта делится на количество запущенных, а не проданных рабочих мест), кстати и стоимость поддержки, часто предлагается в размере 25 % от стоимости проекта, вместо типичных 15—18% от стоимости программного обеспечения.

69

Также сравнимы с параметрами R/3 оказываются такие показатели, как «стоимость внедрения/стоимость ПО» (стоимость внедрения превышает стоимость собственно программного обеспечения от 2 до 15 раз, при типичном показателе около 3—5, при этом стоимость ПО считается по количеству реально заработавших рабочих мест) и процент «внедряемости» (процент внедренных решений от общего количества проданных, что составляет цифру иногда существенно ниже 70%, типично около 60%, для «успешных» систем).

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

Можно было бы об этом и не говорить, в конце концов бизнес на ПО

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

От MRP II к ERP

	Бюджет доходов									Cash-flow
	(портфель заказов)									diagramm
							Платежный
				Бюджет			календарь
				постоянных
				расходов
		Бюджет
						Бюджет
		расходов
				Бюджет		закупок
				переменных
				расходов
						Бюджет
						запасов

Рис. 2. Система финансового планирования

70