Выбор системы

ЛЕКЦИЯ 14

 ВЫБОР СИСТЕМЫ

Основные критерии выбора системы

Процесс выбора системы в общем случае может быть пред­ставлен как процесс выбора из большого коли­чества альтернатив:

• уровень системы: «коробочная», средний или высокий,

• уровень исполнения: управление цехом или производством,

• тип принимаемого решения,

• и так далее.

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

Рекомендуемые материалы

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

Основным критерием, которым следует руководствоваться при выборе системы, должен быть критерий удов­летворения потребнос­тей бизнеса предприятия. Потребности бизнеса формулируются в терминах бизнеса. В табл. 10 приведены типичные формулировки це­лей бизнеса, которые должны быть достигнуты с помощью внедре­ния информационных технологий [121]. Таблица составлена подан­ным опроса руководителей, отвечающих за фи­нансовые результаты деятельности предприятий и корпораций, т. е. лиц, участвующих в принятии решений при выборе системы, но не являющихся специ­алистами в информационных технологиях.

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

Поэтому при выборе системы потребности бизнеса, сформули­рованные в терминах бизнеса, должны быть конвертированы в тех­нические и экономические требования к системе, сформулирован­ные в соответствующих терминах:

• функциональные возможности,

• совокупная стоимость владения,

• перспективы развития, поддержки и интеграции,

• технические характеристики. Ниже эти критерии рассматриваются подробнее.

Функциональные возможности

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

Таблица 10

процесса ведения бухгалтерского учета; если требуется достичь кон­курентного преимущества за счет сокращения сроков разработки новых видов продукции, то одно из решений может заключаться в выборе системы CAD/CAM (САПР). Для того чтобы определить до­статочность функциональных возможностей системы, необходимы два компонента:

• Стратегия развития бизнеса и контекстное описание бизнеса.

• Формализованное описание деятельности предприятия.

Луч­ше всего, если это будут модели деятельности предприятия, выполненные согласно методикам структурного анализа: ди­аграммы согласно стандартам IDEFO или IDEF3; диаграммы потоков данных или модели бизнес-процессов. В идеальном случае стратегия развития бизнеса и контекстное описание бизнеса должны содержаться в стратегическом плане ав­томатизации предпри­ятия. Если исходные данные для выбора систе­мы отсутствуют, то в план выбора системы необходимо включить этап по подготовке исходных данных для выбора системы, иными словами, разработать Техническое задание на систему.

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

В пользу этого можно привести следующие основные аргументы:

• внешний консультант обладает особыми навыками и знания­ми, которых может не быть у сотрудников ор­ганизации;

• даже если в организации и есть требуемые квалифицирован­ные кадры, то они могут быть заняты решением других про­блем;

• внешний консультант может показать реальное положение дел, так как он независим от организации-заказ­чика;

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

Так что же реально можно получить на этапе определения по­требностей предприятия в информационной системе?

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

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

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

Наиболее просто проблема определения достаточности функци­ональной полноты решается для систем началь­ного и среднего уровня. Для систем высшего уровня определяются:

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

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

• Как система поддерживает производственные поставки, а также электронные средства поставки.

• Насколько полно система управляет процессом материально-технического снабжения, а также складирова­нием продукции и планированием ее доставки.

• Как система учитывает работу с клиентами. Требуется оценить, как в системе поддерживается планирование спроса, автома­тизация работы с посредниками и торговыми агентами, на­сколько гибко осуществляется обработка заказов клиентов, а также осуществляется учет сервисного обслуживания.

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

Совокупная стоимость владения (ТСО — Total Cost of Ownership) информационной системой — сравнительно новое понятие, кото­рому в последнее время уделяется самое пристальное внимание в литературе . Под совокупной стоимостью владения пони­мается сумма прямых и косвенных затрат, которые несет владелец сис­темы за период жизненного цикла последней.

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

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

• время жизни существующей на предприятии системы;

• время проектирования новой системы;

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

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

Вариант информационной системы с более коротким жизнен­ным циклом предпочтителен для дальнейшего использования. На рис. 35 самым рациональным является вариант А.

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

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

Рис. 35

1 — точка завершения проектирования существующей системы; 2 — точка завершения внедрения суще­ствующей системы; 3 — точка ввода в эксплуатацию новой системы; X— точка выбора новой системы; А — точка возврата 90% инвестиций в новую информационную систему (вариант А); В — точка возврата 90% инвестиций в новую информационную систему (вариант В); С — точка возврата 90% инвестиций в новую информационную систему (вариант С)

• при достижении доходов от эксплуатации существующей сис­темы порядка 90% вложенных в нее инвести­ций;

• при превышении эксплуатационных затрат на систему над

доходами от ее использования и др.

Прямые и косвенные затраты могут включать следующие состав­ляющие.

Прямые затраты.

1.1. Основные затраты:

• создание информационной системы;

• оборудование — серверы, клиентские места, периферия, сете­вые компоненты;

• программное обеспечение (ПО);

• приложения, утилиты, управляющее ПО;

• обновление (модернизация).

1.2. Эксплуатационные затраты:

• управление задачами (сетью, системой, массивами памяти);

• поддержка работоспособности системы — персонал, функцио­нирование справочной службы, обучение, за­купки, подготовка кон­трактов на поддержку системы;

• разработка инфраструктуры, бизнес приложений.

1.3. Прочие затраты:

• создание коммуникаций — глобальные сети, взаимодейст­вие с поставщиками сервиса, удаленный дос­туп, Internet, доступ клиента;

• управление и поддержка — аутсорсинг, сопровождение, спра­вочная система.

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

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

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

Таблица 11

Перспективы развития, поддержки и интеграции

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

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

Технические характеристики

К техническим характеристикам системы относятся следующие:

• архитектура системы;

• масштабируемость;

• надежность, особенно в части выполнения критических биз­нес-приложений;

• способность к восстановлению при сбоях оборудования;

• наличие средств архивирования и резервного копирования данных;

• средства защиты от преднамеренных и непреднамеренных тех­нических нападений;

• поддерживаемые интерфейсы для интеграции с внешними си­стемами.

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

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

Риски и управление рисками

Анализ факторов риска

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

Анализ факторов риска предваряют: планирование мероприятий для снижения влияния факторов риска на ис­ход проекта и принятие решений на различных этапах процесса создания автоматизиро­ванной системы.

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

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

Все риски делятся на две группы:

1) бизнес-риски,

2) риски, связанные с жизненным циклом системы.

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

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

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

Вторая группа рисков может быть разделена на две подгруппы:

1) технические риски, связанные с реализацией технических ре­шений или работ, связанных с технологией внедрения. Например, инсталляция ПО на какую-либо платформу;

2) риски, связанные с управлением процессом создания и под­держки системы. Например, достижение тре­буемого качества в за­данные сроки при заданных бюджетных ограничениях.

Как правило, все наиболее известные поставщики решений в области автоматизации деятельности предпри­ятий, системные ин­теграторы и консультационные компании, разработчики приклад­ного ПО имеют собствен­ные методы управления рисками, которые включают в себя:

• методику выделения факторов риска,

• методы количественной оценки влияния факторов на такие параметры проекта, как возможное увели­чение стоимости решения или времени его реализации в целом или отдельных его компонентов,

• подходы к снижению влияния факторов риска на успех проекта.

На рис. 36 приведена типовая схема процедуры управления рис­ками.

Для минимизации бизнес-рисков используются следующие под­ходы:

• минимизация инвестиционных рисков,

• максимально возможная стандартизация всех компонентов

решения.

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

Примерный перечень стандартизируемых компонентов имеет сле­дующий вид:

• автоматизируемые бизнес-процессы предприятия,

• процессы самой системы,

• прикладное ПО,

• стандарты СУБД, операционные системы, сетевые протоко­лы и т. д.,

• стандарты на оборудование,

• стандарты на рабочие станции.

Рис. 36

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

Некоторые рекомендации по выбору системы

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

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

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

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

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

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

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

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

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

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

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

Заказная или адаптированная система

Основные аргументы за и против этих вариантов приведены в табл. 12.

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

• при уникальности автоматизируемых процессов,

• при отсутствии на рынке требуемой системы.

Таблица 12

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

Отечественная или зарубежная система

Существуют два полярных мнения:

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

2) единственными системами, которые позволяют полностью автоматизировать все аспекты управления предприятием, являются зарубежные системы типа ERP. Поэтому, несмотря на их более вы­сокую стоимость, предприятиям следует выбирать именно ERP-системы, жизнеспособность которых подтверждена мировым опы­том.

Обобщая эти два мнения, можно сказать, что в данном случае определяющими являются следующие крите­рии:

• функциональная полнота,

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

Уровень системы

К сожалению, для многих руководителей наиболее часто первым и практически единственным критерием слу­жат затраты на созда­ние системы. Иногда затраты на создание ассоциируются только со стоимостью программно-аппаратных средств. Однако такой подход может привести к покупке очередной коробки, которая будет пы­литься на полке, или, в лучшем случае, к установке системы только в отделе АСУ предприятия.

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

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

• функциональная полнота,

• готовность руководства к реорганизации бизнес-процессов.

УПРАВЛЕНИЕ ПРОЦЕССОМ ВНЕДРЕНИЯ И ЭКСПЛУАТАЦИИ

Типовой план внедрения

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

Впервые подобный план был создан в компании Oliver Wight для внедрения первых версий MRPII. Опыт показывает, что дан­ной стратегии придерживаются в той или иной степени практи­чески все фирмы.

На рис. 37 приведен типовой план.

Ниже приведено описание этапов.

1. Предварительное обследование и оценка состояния Цель этапа — установить, в каком состоянии находится пред­приятие. Полезно приглашение внешних консультантов. Результа­ты: краткосрочный план действий, опре­деление возможных на­правлений работ и рекомендации по стратегии внедрения.

2. Предварительная переподготовка

Цель — дать ведущим менеджерам представление о том, что включает в себя процесс внедрения. Дело в том, что надо преодо­леть различия в понимании процесса разными категориями со­трудников. Некоторые считают, что MRPII/ERP — это компью­терная система. Другие видят ее как систему управления производ­ством и запасами. Третьи — как систему, объединяющую подраз­деления. Для руководителей важно прийти к единому пониманию будущего эффекта и необходимых ресурсов.

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

3. Техническое задание

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

4. Технико-экономическое обоснование — ТЭО (анализ «затра­ты—эффект»)

Анализ «затраты—эффект» позволяет принимать обоснованные решения и подтверждает финансовую необ­ходимость изменений.

Рис. 37

Нулевая точка — это тот момент времени, когда принято формальное решение о внедрении

Он показывает экономический эффект: рост производительнос­ти, снижение затрат и т. п. Объекты анализа: затраты на внедрение компьютерных систем (в том числе конкретных подсистем, напри­мер бухучета и под­держку математического обеспечения), образо­вание и т. п.

5. Организация проекта

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

Управляющий комитет — руководитель предприятия и его заме­стители. Регулярные совещания 1—2 раза в ме­сяц.

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

Рабочая команда по внедрению разбивается на логические группы по подразделениям, производственным на­правлениям и програм­мам внутри компании. Команда ответственна за ежедневное управ­ление проектом. Осу­ществляет контроль на уровне фирмы и ее отделов. В нее входят специалисты в различных областях. Члены команды могут работать по отдельным задачам. Оптимальное чис­ло людей в команде — 6—7 человек (не более 10).

Ниже более подробно описаны функции организаторов проекта.

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

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

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

Исполнительный директор представляет группу высших управ­ленцев и несет персональную ответствен­ность за успех внедре­ния.

Группы улучшения качества управления. Это малые группы, пред­назначенные для решения различных задач. За­дачи могут включать обследование перед внедрением, разработку процедур ведения баз данных, совершенство­вания учета и т. п.

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

Работа групп координируется во избежание конфликтов и дуб­лирования.

6. Выработка целей

Этот шаг определяет качественные и количественные ожидае­мые результаты. Важно ясное их описание. Цели описываются конк­ретно: «Мы ожидаем, что улучшение в обслуживании заказчиков составляет 75—95%. Кроме того, мы ожидаем снижения запасов на 30%, на 11% уменьшение затрат на материалы...»

7. ТЗ на управление процессами

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

8. Начальная переподготовка

Цель — переподготовка сотрудников, которые затем будут рабо­тать по внедрению системы.

Пример фирмы General Dynamics Land Systems — хорошая ил­люстрация процесса обучения. В компании были организованы не­дельные курсы для высшего персонала по MRPII. Для технических руководителей — более под­робные курсы по MRPII. При этом фир­ма использовала своих управленцев для обучения людей, так что шла пе­редача знаний и информации от управленцев — производ­ственникам.

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

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

9. Планирование и управление верхнего уровня

Этот шаг в ERP, MRPII или ЛТ рекомендуется в качестве на­чального при построении системы. Такое начало процесса не требу­ет значительных затрат, но дает большой эффект. Если этого не сде­лать, то неустойчивость пла­нов высокого уровня приведет к лави­нообразному эффекту: люди утратят веру в информацию и возродят нефор­мальную систему.

10. Управление данными

Есть два типа данных — первостепенные и второстепенные, не­строгие.

Первостепенные данные — это данные, неточность которых не­допустима: данные о запасах, состав изделия и применяемость, тех­нология (описания), маршрутные технологии.

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

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

Если маршрутные технологии неточны — это означает, что последовательность операций неправильна; рабочие центры зада­ны неверно или нормы времени существенно неточны. Все это серьезно влияет на SFC (управление цехом) и планирование по­требных мощностей.

Минимальный уровень точности данных для современных сис­тем АСУП составляет: запасы — 95%; состав изделия и применяе­мость — 98%; маршрутные технологии — 95%.

Обеспечение требуемой точности данных — наиболее трудоем­кая часть работы по внедрению.

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

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

Ответственность за точность информации должна быть инди­видуальной и коллективной (по подразделе­ниям).

Обеспечение инструментальными средствами. Нужна простая в использовании автоматизированная система с быстрым и разгра­ниченным доступом.

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

Существует несколько различных методов проверки точности информации о составе изделий и применяе­мости материалов, на­пример анализ внеплановых отпусков/поступлений материальных ресурсов или аудит.

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

При аудите берется состав изделия и анализируется его точность.

Метод аудита вполне пригоден для проверки информации о марш­рутах.

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

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

11. Одновременное внедрение различных технологий организа­ции и управления

Как правило, внедряется сразу несколько новых технологий управления: ЛТ, работа с кадрами, общий контроль качества, САПР и т. п.

12. Программное обеспечение (ПО)

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

13. Опытный пример

Есть три способа начала использования новой системы:

1. Параллельная стратегия — для случая, когда старую рабо­тающую систему необходимо заменить новой. Например, п/с «Зар­плата». Одновременно работают старая (ручная) и новая система, и их выходные документы сравниваются. Если они согласуются длительное время, можно переходить на новую систему. Проблема в том, что большинство предприятий, внедряющих АСУП, заме­няют программным обеспечением неавтоматизирован­ный вариант, а не одну часть программного обеспечения другой.

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

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

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

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

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

Свойство этой стратегии — сосредоточение на «узком месте» в производственном процессе — упрощает внедрение. Группе в 10— 12 человек проще сконцентрироваться на внедрении новой систе­мы в одном сегменте бизнеса, чем 200 людям внедрять систему на всей фирме.

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

Опыт показывает, что во многих случаях можно за 3—5 месяцев «расшить узкое место» и быстро достичь на­меченных результатов.

14. Получение результатов

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

15. Анализ текущего состояния

Если на первом этапе деятельности анализ определял возмож­ные улучшения, открыв последовательность работ по внедрению, то анализ текущего состояния выявляет, какие задания выполня­лись хорошо (например, достигнута высокая точность данных), а какие плохо (например, объемное планирование или составление план-графика). Затем можно сфокусировать внимание на этих про­блемах и приложить усилия для их разрешения.

Бесплатная лекция: "4 - Флористические регионы суши" также доступна.

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

16. Постоянная переподготовка

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

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

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