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

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

При отсутствии системы управления подобным проектом он быстро становится безнадёжным. Таким проектам уже посвящена литература, например, книга Эдварда Йордана «Death March», что буквально можно перевести как «похоронный марш». Безнадёжный проект - это такой проект, параметры которого отклоняются от заданных более чем на 50 %. Обычно проект переходит в разряд безнадёжных, если занижены вдвое сроки, количество участников, финансирование, или завышены вдвое требования к параметрам внедряемой системы. Одной из главных причин перехода проекта в безнадёжные является завышенный оптимизм заказчиков и разработчиков в отношении возможностей новых технологий создания систем ERP.

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

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

Правило 1. «Собственниками» системы должны быть её пользователи. Здесь термин «собственник» употребляется в широком смысле. Под «собственником» проекта понимается коллектив, задумавший, реализовавший проект и несущий за него полную ответственность. Проект такого масштаба не может быть в ведении исключительно ВЦ, отдела АСУП и т. п. Если он находится в ведении исключительно отдела АСУП, то пользователи отчуждаются от проекта, ставятся в позицию людей, которые ожидают готового результата и не несут за него никакой ответственности. В полномасштабных системах «собственником» не может быть и какое-либо функциональное подразделение - финансовое, производственное, технологическое и т. п. Ими должны быть все пользователи системы.

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

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

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

1. Наличие собственного опыта или достаточных знаний о работе пользователей.

2. Глубокие знания производственного процесса на предприятии.

3. Хорошая репутация и хорошие отношения внутри предприятия.

4. Опыт работы в коллективах, выполнявших проекты.

5. Опыт работы с людьми и организаторские способности.

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

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

Правило 3. Чёткие и достижимые цели. Первый вопрос, на который у компании должен быть ясный ответ - «Зачем Вы делаете этот проект?». Ответов может быть несколько, среди них такие:

♦ достичь экономии средств;

♦ увеличить объёмы производства;

♦ решить стратегические задачи;

♦ интегрировать функции управления;

♦ улучшить информационное обеспечение руководителей и управленческого персонала.

Чётко сформулированные цели становятся руководящими принципами для проекта в целом.

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

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

Цели должны быть достижимы. У компании и разработчиков системы должны быть достаточно высокие шансы на успешное завершение проекта. Можно сформулировать очень заманчивые цели, например, достичь класса А для систем MRP. Обычно к этому склонны консалтинговые фирмы, поскольку такие цели приводят к большому объёму их работ. Однако, часто выясняется, что работники предприятия по своему уровню подготовки, опыту, деловым качествам не готовы к этому. Такой подход приводит к отторжению системы.

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

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

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

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

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

Правило 5. Требования к системе должны формулироваться до демонстрации программного продукта. Часто, когда предприятие решает начать поиск программной системы, проектная команда устремляется на демонстрации и презентации. Это ошибка. Ни одна, даже самая опытная команда не в состоянии полностью оценить программную систему только лишь на основе демонстрации. Этому должен предшествовать этап формулирования требований, а в ряде случаев - изучения методологии, заложенной в подобные программные системы. Пожалуй, самым ярким примером, иллюстрирующим высказанное положение, является процесс выбора систем МЮРШЕИР для российских предприятий.

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

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

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

Правило 6. Модификаций программных продуктов не должно быть.

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

1. Возможны нарушения внутреннего единства системы, её интеграционных свойств.

2. Возможны программные ошибки.

3. Накапливаются отличия реальной программной системы от её документации.

4. Модификация может затруднить переход к новым версиям программной системы.

Ещё одно средство избавиться от неоправданных изменений в программной системе - модифицировать не программный продукт, а внести изменения в бизнес-процессы.

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

Правило 7. Быть готовыми к решению сложных проблем. Проектной команде следует учиться решению сложных проблем, а не только проектных задач. Задачи - это действия, которые известны, как правило, заранее и должны быть выполнены. Проблемы - это трудности, вопросы, неопределённости, которые надо разрешить до начала процесса внедрения. Хорошая методология проектирования может помочь в определении перечня задач. Но ни одна методология не в состоянии предсказать, какие проблемы возникнут в ходе выполнения проекта. Это особенно верно для полномасштабных систем, где проблема в одной части может препятствовать прогрессу в другой части системы.

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

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

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

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

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

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

Ниже приводится описание проекта системы ERP для части компании British Aerospace, выполняющей оборонные заказы.

British Aerospace Military Aircraft & Aerostructures (В Ae МА&А) - часть корпорации British Aerospace (BAe), объединяющая КБ и заводы, обеспечивающие полный цикл разработки, производства и поставки заказчику боевых самолётов. Номенклатура изделий включает:

♦ Eurofighter 2000,

♦ Tornado (Strike & Defence),

♦ Harrier,

♦ Hawk,

♦ T-45,

♦ Gripen,

♦ Maritime Patrol (Nimrod).

В дополнение к указанным основным изделиям В Ae МА&А производит также некоторые узлы и компоненты для гражданских самолётов по программам Airbus и Boeing.

В Ае МА&А - крупнейшее подразделение ВАе и имеет более 20,000 работников, распределено по 8 площадкам (Warton, Brough, Chadderton, Dunsfold, Famboro, Filton, Prestwick, Samlesbury). Основная площадка в Warton недалеко от Manchester. Объём продаж за 1997 год ожидается ~ 3,0.В.$. Портфель заказов в настоящее время ~ 10,0.В.$. Заказчики - по всему миру. Ключевые заказчики - Мин. Обороны США и Великобритании. Ряд проектов ведётся в кооперации с фирмами Германии, Италии, США, Швеции.

ВАе МА&А разработана и принята программа Операционной Эффективности и Совершенства (OEI - Operational Efficiency Improvements). Программа состоит из трёх направлений, в том числе Интегрированное Конструирование Продукции (Integrated Product Design), Поддержка Заказчика (Support the Customer), Управление и Поддержка Интегрированной Бизнес-модели (Integrated Business Logistic and Support - IBLS).

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

В качестве программного решения задач IBLS выбрана Интегрированная Система Управления Ресурсами Предприятия компании BAAN - система BAANIV.

Контракт между ВАе МА&А и ВAAN подписан в январе 1997 года.

Контракт обеспечивает закупку 3,000 лицензий конкурентных пользователей BAAN IV.

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

British Aerospace (ВАе) собирается модернизировать производство реактивных самолётов Eurofighter и Harrier, заменив 200 устаревших производственных систем единым программным обеспечением, охватывающим 5 предприятий и 3 тыс. пользователей.

Система планирования ресурсов предприятия (ERP), внедрённая в оборонное самолётостроение ВАе, резко сократит затраты на разработку и поддержку существующих систем управления на предприятиях.

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

Работы над проектом ведутся под управлением Корпорации по Научно-Исследовательским Работам в области Компьютеризации (CSC). Ещё в 1993 году ВАе поручила CSC проведение работ по ИТ, что обошлось ей в десятки миллионов фунтов стерлингов.

Г-н Уилкинсон, руководитель направления по работам с крупными заказчиками CSC, заявил: «Данный проект по ERP - один из наиболее значимых проектов CSC в Европе, даже если рассматривать его на мировом уровне».

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

«Системы в старых подразделениях по самолётостроению росли органично, но обособленно. Обычный случай - множественные источники данных, которые несовместимы. Старые системы сдерживали гибкость и конкурентоспособность ВАе», - подтвердил г-н Уилкинсон. В CSC также отметили, что системы могут привнести унификацию как в организацию работы отдельных предприятий компании, так и в функции, выполняемые ими.

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

Порядка 100 служащих в CSC и ВАе были включены в работу над проектом - в подготовку планов по переводу данных в новую систему и в построение временных связующих прикладных программ и интерфейсов. В конце лета 1998 года система BAAN впервые была внедрена на заводе ВАе в городе Салмесбере. В течение 3 ближайших лет BAAN будет внедрена на четырёх других производственных предприятиях, включая Фарборо и Престон.

Данная система ERP будет установлена на серверах SUN Microsystems и будет использовать СУБД Oracle.

Работы по проекту В А ведутся на основе календарного плана, рассчитанного до 2000 года включительно.

Более крупным является ещё один проект в аэрокосмической отрасли -проект компании «Boeing».

Вот некоторые данные о проекте.

Данные о заказчике: Компания: Boeing Commercial Airplane Group (BCAG); Направление бизнеса: коммерческое самолётостроение (Аэрокосмическая и оборонная отрасли промышленности).

Тип производства: проектирование-на-заказ, производство-на-заказ.

Количество пользователей: 18271.

Особенности проекта:

♦ Крупнейшее в мире внедрение системы ERP.

♦ 19 установок были внедрены в течение февраля 1996 - декабря 1997 гг.

♦ Информация о 412467 компонентах была перенесена из устаревших систем в единую ERP-систему.

♦ Внедрение начато в мае 1998 года.

♦ Для отделов инжиниринга и продаж окончание работ назначено на июнь 1999 года.

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

⇐Выводы к главе 10. | Система управления предприятием типа ERP | Выводы к главе 11.⇒